Closed Bug 1163911 Opened 4 years ago Closed 4 years ago

Intermittent test_viewport_resize.html | undefined assertion name - got data:,c, expected data:,a

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox39 --- unaffected
firefox40 --- unaffected
firefox41 --- fixed
firefox-esr31 --- unaffected
firefox-esr38 --- unaffected

People

(Reporter: cbook, Assigned: jdm)

References

()

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

https://treeherder.mozilla.org/logviewer.html#?job_id=9768126&repo=mozilla-inbound

05:45:31 INFO - 1136 INFO TEST-UNEXPECTED-FAIL | dom/html/test/test_viewport_resize.html | undefined assertion name - got data:,c, expected data:,a
Josh, this is hella-frequent.
Blocks: 1135812
Component: DOM: Core & HTML → DOM
Flags: needinfo?(josh)
Flags: needinfo?(josh)
Keywords: leave-open
Assignee: nobody → josh
I caught a test failure with a bunch of extra debugging information: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/josh@joshmatthews.net-2e4bf8f46ff9/try-macosx64/try_snowleopard_test-mochitest-2-bm106-tests1-macosx-build1361.txt.gz

Comparing it with a working run (http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/josh@joshmatthews.net-2e4bf8f46ff9/try-macosx64/try_snowleopard_test-mochitest-2-bm106-tests1-macosx-build1356.txt.gz), it's interesting that the media feature change notification simply doesn't happen in the failing run, which would explain the specific test failure. This may also jive with the recent information in bug 1135812.
The other difference here is that while both run the queued image load task after the first test assertion, the passing run doesn't dispatch the load event (presumably due to the URI equality check in https://dxr.mozilla.org/mozilla-central/source/dom/base/nsImageLoadingContent.cpp#876), while the failing run does. Perhaps this is caused by johns' previous concern that the queued image load task in HTMLImageElement.cpp doesn't block the document's load event properly.
Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=a42794d01122 turned out really nice! I think the load blocking is on to something.
Comment on attachment 8615801 [details] [diff] [review]
Make responsive images block the document load event while the load task is queued

Review of attachment 8615801 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah this would definitely explain it, and probably most of the other intermittent too!

This should be checked by a dom peer though, I'm not familiar with the OnLoad machinery other than its existence
Attachment #8615801 - Flags: review?(jst)
Attachment #8615801 - Flags: review?(john)
Attachment #8615801 - Flags: feedback+
Attachment #8615801 - Flags: review?(jst) → review+
Comment on attachment 8615801 [details] [diff] [review]
Make responsive images block the document load event while the load task is queued

Approval Request Comment
[Feature/regressing bug #]: 1135812
[User impact if declined]: Frequent oranges for shepherds, and intermittently confusing experience for web developers.
[Describe test coverage new/current, TreeHerder]: Fixes an intermittently failing test.
[Risks and why]: None. 
[String/UUID change made/needed]: None.

This should be approved/not approved in conjunction with bug 1135812.
Attachment #8615801 - Flags: approval-mozilla-beta?
Comment on attachment 8615801 [details] [diff] [review]
Make responsive images block the document load event while the load task is queued

Bug 1135812 will ship in 41. This fix is not required in 40. Beta-
Attachment #8615801 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Looks like this worked!
Status: NEW → RESOLVED
Closed: 4 years ago
Keywords: leave-open
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.