Closed Bug 945189 Opened 11 years ago Closed 11 years ago

Intermittent TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug602838.html | Async script should have run first.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla29
Tracking Flags:
Tracking Status
firefox27 --- unaffected
firefox28 --- fixed
firefox29 --- fixed
firefox-esr24 --- unaffected
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed

People

(Reporter: cbook, Assigned: hsivonen)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Finish sjs explicitly
3.03 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
b2g_emulator_vm mozilla-inbound opt test mochitest-1 on 2013-12-01 18:49:56 PST for push 08fd80f4b2bf slave: tst-linux64-ec2-027 https://tbpl.mozilla.org/php/getParsedLog.php?id=31302008&tree=Mozilla-Inbound 33276 ERROR TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_bug602838.html | Async script should have run first.
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #118) > Try run of bug 943149 backed out: > https://tbpl.mozilla.org/?tree=Try&rev=0a2880ec5028 Hah, that actually made it way worse.
This is a constant failure during the debug emulator mochitests on pine.
Luke, 500+ green runs without a failure on the inbound changeset prior say that bug 941827 is what caused this. I attempted a Try run of it backed out, but hit conflicts. Can you please take a look? Rev 4c27e14de1af (push prior to bug 941827) - https://tbpl.mozilla.org/?tree=Try&rev=9c4a93894a3e Rev f4a802140bc7 (bug 941827) - https://tbpl.mozilla.org/?tree=Try&rev=ddb666e15925
Blocks: 941827
status-b2g-v1.2: --- → unaffected
status-firefox27: --- → unaffected
status-firefox28: --- → affected
status-firefox29: --- → affected
status-firefox-esr24: --- → unaffected
Flags: needinfo?(luke)
Boris: it looks like this test is actually testing the 'async' attribute of scripts and the order of execution. The test failure indicates that two scripts are executing in the wrong order. The patch in question simply enabled us to use the off-main-thread parsing when cpucount=1 (which is true on linux, last I saw) which is what made this start failing, but the bug was pre-existing. What I don't know is if the async script execution ordering is valid (and the test is wrong) or if the bug is in the browser. Could you lend your expertise?
Flags: needinfo?(luke) → needinfo?(bzbarsky)
Hmm. That's more a question for Henri, I think. The test seems to claim that the async script at the end there needs to run before we've had a chance to hit the web server and come back with the sjs. But it seems to me that's timing-dependent in the off-main-thread parse case, and I don't believe anything actually enforces that ordering... Henri, _should_ something enforce it?
Flags: needinfo?(bzbarsky) → needinfo?(hsivonen)
Disabled on gonk in https://hg.mozilla.org/integration/mozilla-inbound/rev/bc042e0c0db5 while you consider that.
Whiteboard: [leave open][test disabled on gonk]
(In reply to Boris Zbarsky [:bz] from comment #141) > The test seems to claim that the async script at the end there needs to run > before we've had a chance to hit the web server and come back with the sjs. No, that's not what the test is suppose to claim. It is supposed to claim we spin the event loop enough within 0.2 seconds to run the data: URL scripts before the timer in the .sjs fires. > But it seems to me that's timing-dependent in the off-main-thread parse > case, and I don't believe anything actually enforces that ordering... There is no true enforcement--just the assumption that the 0.2-second delay in the .sjs is long *enough*. We could either make the timer in the .sjs take a longer time to fire or we could make the .sjs otherwise stateful and have one of the data: URL scripts XHR into the .sjs to get the .sjs do what it currently does off a timer.
Flags: needinfo?(hsivonen)
The latter sounds good to me. Do you have time to do that, or should I find someone else?
Flags: needinfo?(hsivonen)
I'll try to fix this.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Flags: needinfo?(hsivonen)
Attachment #8349348 - Flags: review?(bzbarsky)
Comment on attachment 8349348 [details] [diff] [review] Finish sjs explicitly r=me
Attachment #8349348 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [leave open][test disabled on gonk]
status-firefox28: disabled → affected
status-firefox29: disabled → fixed
Target Milestone: --- → mozilla29
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: