http/tests/misc/DOMContentLoaded-event.html is flaky

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

http/tests/misc/DOMContentLoaded-event.html is flaky on Yosemite WK2. Looks like its 10 ms timer takes a very long time to fire, so loading of a resource with 250 ms timeout finishes first.

[Alexey Proskuryakov]

Created attachment 250860 [details]
proposed fix

[Chris Dumez]

Comment on attachment 250860 [details]
proposed fix

View in context: https://bugs.webkit.org/attachment.cgi?id=250860&action=review

> LayoutTests/http/tests/misc/DOMContentLoaded-event.html:29
> +                    log('FAILED: ' + (newTimestamp - timetamp) + " ms between DOMContentLoaded and load events");

Based on the if check, newTimestamp == timetamp here. So it will always be 0ms unless I am misreading.

[Chris Dumez]

Comment on attachment 250860 [details]
proposed fix

View in context: https://bugs.webkit.org/attachment.cgi?id=250860&action=review

>> LayoutTests/http/tests/misc/DOMContentLoaded-event.html:29
>> +                    log('FAILED: ' + (newTimestamp - timetamp) + " ms between DOMContentLoaded and load events");
> 
> Based on the if check, newTimestamp == timetamp here. So it will always be 0ms unless I am misreading.

Also typo in the variable name: timetamp -> timestamp

[Alexey Proskuryakov]

Created attachment 250963 [details]
proposed fix

[Chris Dumez]

Comment on attachment 250963 [details]
proposed fix

View in context: https://bugs.webkit.org/attachment.cgi?id=250963&action=review

> LayoutTests/http/tests/misc/DOMContentLoaded-event.html:26
> +                if (timestamp != newTimestamp)

I believe we want to check that the DOMContentLoaded fires *before* the window load event. I don't believe the current check is sufficient for this purpose. newTimeStamp > timeStamp would be more correct but the issue is that timeStamp may be uninitialized if DOMContentLoaded hasn't fired yet.
How about simply have a global 'hasDOMContentFired' boolean (initially false), setting it to true in the DOMContentLoaded handler, and then having a check in the window load handler to make sure hasCOMContentFired is true?

> LayoutTests/http/tests/misc/DOMContentLoaded-event.html:36
>          <p>You should see a note about the DOMContentLoaded event being fired and bubbled, a timer being called, and then the load event being fired.</p>

This still mentions a Timer being called.

[Build Bot]

Comment on attachment 250963 [details]
proposed fix

Attachment 250963 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/6399118071037952

New failing tests:
http/tests/misc/DOMContentLoaded-event.html

[Build Bot]

Created attachment 250976 [details]
Archive of layout-test-results from ews102 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 250963 [details]
proposed fix

Attachment 250963 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5594552584896512

New failing tests:
http/tests/misc/DOMContentLoaded-event.html

[Build Bot]

Created attachment 250981 [details]
Archive of layout-test-results from ews106 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Alexey Proskuryakov]

Created attachment 250999 [details]
proposed patch

> I believe we want to check that the DOMContentLoaded fires *before* the window load event. I don't believe the current check is sufficient for this purpose.

Well, the test in the previous patch would fail (have different output) if DOMContentLoaded didn't fire, but I made it more explicit.

[Chris Dumez]

Comment on attachment 250999 [details]
proposed patch

r=me

[WebKit Commit Bot]

Comment on attachment 250999 [details]
proposed patch

Clearing flags on attachment: 250999

Committed r182940: <http://trac.webkit.org/changeset/182940>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.