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.
Created attachment 250860 [details] proposed fix
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.
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
Created attachment 250963 [details] proposed fix
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.
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
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
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
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
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.
Comment on attachment 250999 [details] proposed patch r=me
Comment on attachment 250999 [details] proposed patch Clearing flags on attachment: 250999 Committed r182940: <http://trac.webkit.org/changeset/182940>
All reviewed patches have been landed. Closing bug.