Opened 15 years ago

Closed 14 years ago

#2757 closed defect (fixed)

dojo.i18n test regression on mozilla

Reported by: Adam Peller Owned by: alex
Priority: high Milestone: 0.9
Component: TestFramework Version: 0.4.2
Keywords: Cc:
Blocked By: Blocking:


tests fail due to some problem in the loader. URLs have test/test/...

Change History (8)

comment:1 Changed 15 years ago by Adam Peller

In #2879, cougar notes that this appears to be tied to the xhr unit test

comment:2 Changed 15 years ago by alex

Resolution: fixed
Status: newclosed

(In [8388]) fixes #2757

comment:3 Changed 15 years ago by alex

(In [8416]) break stuff up into individual test fixtures to assist in debugging. Refs #2757

comment:4 Changed 15 years ago by (none)

Milestone: 0.9M2

Milestone 0.9M2 deleted

comment:5 Changed 15 years ago by James Burke

Milestone: 0.9
Resolution: fixed
Status: closedreopened

The fix in r8388 bothers me, in particular this part:

    uri = (new dojo._Url(window.location, uri)).toString(); 

I prefer not to have the dojo._Url dependency or take the cost of creating a new dojo._Url object for each call.

It looks like the original problem is a Firefox only issue IE 6 tested fine w/o the r8388 fix). Could it be related to this mozilla bug:

In that bug, they said using a setTimeout seemed to get around the problem. Maybe we could put a setTimeout around each test group, may in in runner.js? I don't know the doh code well enough though to do the change. Any pointers would be appreciated.

Some info on the bug: The bug happens any time any test loads an test file in DOH's Test Page iframe, then some other test tries to do an XHR from the DOH frame. For instance, this test combination also shows the error:


So it seems to be related to loading a page in that test frame. It looks like the base URL for the XHR is from that test page's location and not DOH's location (even though printing out things like window.location before doing the XHR call report the correct path for the document in the DOH window). So hopefully putting in the right sort of timeout in the DOH calls would do the trick.

Ideally, a setTimeout is used to run each group. After that group completes, a setTimeout is issued for the next group.

Putting the milestone for 0.9 since I don't think it is a 0.9 beta blocker.

comment:6 Changed 15 years ago by James Burke

Owner: changed from Adam Peller to alex
Status: reopenednew

Assigning to Alex, but if he can give some guidance on the right spot in DOH to do the change, I can give a shot at fixing it.

comment:7 Changed 15 years ago by James Burke

Component: InternationalizationTestFramework
Priority: highnormal

comment:8 Changed 14 years ago by alex

Resolution: fixed
Status: newclosed

James: I understand your hesitance with this fix, but it's not just a question of setting timeouts. Since it's related to require()'s+xhr's, it gets triggered in any complex loading (and potential) failure of network I/O. While it may not affect IE, it seems to affect browsers other than FF so I'm going to leave the fix as it is and mark it closed.

Note: See TracTickets for help on using tickets.