Bug 243199
Summary: | Enable lazy iframe loading by default | ||
---|---|---|---|
Product: | WebKit | Reporter: | Sam Sneddon [:gsnedders] <gsnedders> |
Component: | Page Loading | Assignee: | Chris Dumez <cdumez> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | beidson, jensimmons, rbuis, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=243225 | ||
Bug Depends on: | 243198 | ||
Bug Blocks: | 196698 |
Sam Sneddon [:gsnedders]
We should, y'know, have a bug for this.
rdar://97565220
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Sam Sneddon [:gsnedders]
Current WPT results:
/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy-multiple-queued-navigations.html
FAIL Multiple queued lazy load navigations do not crash the page - assert_true: The iframe should be navigated to the resource provided by the latest `src` mutation expected true got false
@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy-multiple-queued-navigations.html:40:16
@http://web-platform.test:8000/resources/testharness.js:2590:30
@http://web-platform.test:8000/resources/testharness.js:2665:37
onload@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy-multiple-queued-navigations.html:51:29
/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html
FAIL Below-viewport srcdoc iframes load lazily - assert_true: The window load event should have fired before the below-viewport srcdoc iframe's subresource loads expected true got false
@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html:52:16
@http://web-platform.test:8000/resources/testharness.js:2590:30
@http://web-platform.test:8000/resources/testharness.js:2637:40
onload@about:srcdoc:2:55
FAIL Below-viewport data: url iframes load lazily - assert_true: The window load event should have fired before the below-viewport data url iframe loads expected true got false
@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html:65:16
@http://web-platform.test:8000/resources/testharness.js:2590:30
@http://web-platform.test:8000/resources/testharness.js:2665:37
onload@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html:96:38
FAIL Below-viewport blob url iframes load lazily - assert_true: The window load event should have fired before the below-viewport blob url iframe loads expected true got false
@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html:72:16
@http://web-platform.test:8000/resources/testharness.js:2590:30
@http://web-platform.test:8000/resources/testharness.js:2665:37
onload@http://web-platform.test:8000/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html:100:38
The former of these is bug 243198, the latter of these I haven't actually filed (but I don't think needs to block shipping, especially while Chrome fails them: https://wpt.fyi/results/html/semantics/embedded-content/the-iframe-element/iframe-loading-lazy.html?label=master&label=experimental&aligned
Jen Simmons
Igalia, any insights into how ready this is to ship? I hear you were perhaps waiting for lazy loading on iFrames to become part of the official HTML spec — which has now happened. Does the implementation need to be updated to match the spec? Is this ready to ship?
Chris Dumez
Pull request: https://github.com/WebKit/WebKit/pull/2748
EWS
Committed 252848@main (461deb6c6dd7): <https://commits.webkit.org/252848@main>
Reviewed commits have been landed. Closing PR #2748 and removing active labels.
Rob Buis
(In reply to Jen Simmons from comment #2)
> Igalia, any insights into how ready this is to ship? I hear you were perhaps
> waiting for lazy loading on iFrames to become part of the official HTML spec
> — which has now happened. Does the implementation need to be updated to
> match the spec? Is this ready to ship?
Yes, should be fine to ship.