Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web compat: Navigating a lazy-loading iframe with location.replace #10213

Open
zcorpan opened this issue Mar 20, 2024 · 3 comments · May be fixed by #10226
Open

Web compat: Navigating a lazy-loading iframe with location.replace #10213

zcorpan opened this issue Mar 20, 2024 · 3 comments · May be fixed by #10226
Labels
compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other topic: navigation

Comments

@zcorpan
Copy link
Member

zcorpan commented Mar 20, 2024

What is the issue with the HTML Standard?

See https://bugzilla.mozilla.org/show_bug.cgi?id=1882670

Some pages use the lazysizes library with lazy-loaded iframes with the intended source in a data-src attribute and a placeholder in the src attribute, as documented in https://github.com/aFarkas/lazysizes?tab=readme-ov-file#how-to but also specify loading="lazy".

The code at https://github.com/aFarkas/lazysizes/blob/gh-pages/src/lazysizes-core.js#L484 invokes location.replace() before the iframe has lazily loaded, which navigates the iframe. When the browser determines that the iframe is sufficiently in view, it invokes the lazy load resumption steps which navigates to the URL in the src attribute (except Chrome doesn't, it seems).

Demo: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12473

I think lazySizes could remove loading attributes on iframes with a lazyload class so that the placeholder src is loaded eagerly and to avoid timing issues with which navigation is the last one, in current Firefox and Safari. Or at least remove loading attribute right before location.replace. (Filed aFarkas/lazysizes#994) cc @aFarkas

But also I think the spec can be changed such that navigating an iframe where will lazy load element steps is true will set the iframe's lazy load resumption steps to null. If script invokes a navigation, it seems reasonable to expect that the script-initiated navigation isn't overridden by lazy-loading the src. Does this match what is implemented in Chromium? cc @domfarolino

cc @rwlbuis @smfr

@zcorpan zcorpan added compat Standard is not web compatible or proprietary feature needs standardizing topic: navigation interop Implementations are not interoperable with each other labels Mar 20, 2024
@annevk
Copy link
Member

annevk commented Mar 20, 2024

What you said in the last paragraph is what makes sense to me.

zcorpan added a commit that referenced this issue Mar 26, 2024
When an iframe element is navigated, the lazy-loading mechanism should not navigate it again.

Fixes #10213.
@zcorpan zcorpan linked a pull request Mar 26, 2024 that will close this issue
5 tasks
@domfarolino
Copy link
Member

Does this match what is implemented in Chromium? cc @domfarolino

Looks like it, yes: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/local_frame.cc;l=504-505;drc=9910d3be894c8f142c977ba1023f30a656bc13fc.

I am not sure about other browsers, and relatedly I am not sure about WPT support for this scenario in general.

@zcorpan
Copy link
Member Author

zcorpan commented Mar 29, 2024

@domfarolino Gecko and WebKit match the current spec (they don't cancel the lazyload).

I'll write WPTs. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other topic: navigation
Development

Successfully merging a pull request may close this issue.

3 participants