window.onload should wait for critical resources linked from css |
||||||||
Issue descriptionMany css1/ tests compare the image output with the expected one. They expected that tests finish when the layout result becomes stable. But the test runner may finish tests before loading some resources. Even worse, the document load event may be dispatched before loading some resources. They're working by chance, and changing the loading timing a bit will break them. They're already flaky, though the failure rate is low. I think window.onload should wait for css1/resources/basebg.gif to be loaded.
,
Dec 20 2016
,
Dec 21 2016
,
Dec 21 2016
,
Dec 22 2016
hiroshige@, do you have any idea? I vaguely remember you talked about something related with the EventSender removal. I was interested in this problem because it blocked loading mojofication, but #1 fixed an existing flakiness: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_tests&tests=css1%2Fbasic%2Fclass_as_selector.html
,
Dec 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a690496daee7b7023cdacdffb572a3efb5499915 commit a690496daee7b7023cdacdffb572a3efb5499915 Author: yhirano <yhirano@chromium.org> Date: Thu Dec 22 07:34:20 2016 Fix pixel-crack-image-background-webkit-transform-scale test with mojo-loading Due to the issue described in https://crbug.com/675870 , the layout test fails with mojo-loading enabled. This CL adds a workaround for the issue. BUG= 675870 , 670409 , 640634 Review-Url: https://codereview.chromium.org/2593403002 Cr-Commit-Position: refs/heads/master@{#440352} [modify] https://crrev.com/a690496daee7b7023cdacdffb572a3efb5499915/third_party/WebKit/LayoutTests/images/pixel-crack-image-background-webkit-transform-scale.html
,
Dec 22 2016
Probably the issue is not related to EventSender removal. Images in CSSs are loaded only if necessary in ElementStyleResources::loadPendingResources(). Probably determining whether it is "necessary" requires layouting, and thus ElementStyleResources::loadPendingResources() can be called in Document::updateStyleAndLayoutTree(). If the first layout is the one in Document::updateStyleAndLayoutTree() called in Document::implicitClose(), then the subresource loadings initiated there (i.e. subresources inside CSSs) do not block Document onload, because Document::implicitClose() is already called. To make Document onload to be blocked in such cases, we might have to call updateStyleAndLayoutTree() or something that causes layouting in the early stage of Document::implicitClose() or even in FrameLoader::checkCompleted(), and then check shouldComplete() condition again. I'm not sure what is expected behavior though...
,
Dec 22 2016
Er, EventSender removal in HTMLLinkElement can affect the behavior related to this, because it modifies the timings of the first layout and document onload (just as mojo-loading modifies them), but probably doesn't affect how we should fix this issue. The key is those in Comment #7, and how the timing dependencies between (1) CSS's loading, (2) (first) layout, (3) CSS subresources loading and (4) document onload. (There're already dependencies between (1)->(4), (2)->(3). Comment #0 looks like proposing adding dependencies between (1)->(2) and (3)->(4).)
,
Dec 28 2016
I really don't think we want to go adding dependencies between the document load event and forcing a layout/style recalc. The timing of when to do a layout/style/paint is not currently spec'd (at least AFAIK and I've had some discussions with various spec owners about it). At most I think we'd want to expose a test-only interface of some kind to force (2) if there isn't already one and provide a way for the test harness to wait for all resources to finish loading independent of window.onload
,
Jan 2 2017
,
Feb 14 2017
OK, let's close this bug. There's no support from loading and CSS tests should handle the issue manually. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by bugdroid1@chromium.org
, Dec 20 2016