• dynamically setting src on an iframe
  • Safari: no load event when setting src.
  • Chrome: fires a load event when setting src
• dynamically setting src on a lazy-loading hidden iframe
  • Safari: fires a load event
  • Chrome: fires a load event

I suppose the PR matches Chrome in that a load event is fired for a javascript: URL in the src attribute unconditionally, but like Safari to evaluate the javascript: URL lazily for loading=lazy iframes.

Just noting that this is on my queue, although @domfarolino and @natechapin might also be interested.

Navigations to javascript:1 from location.href (or following a hyperlink) don't fire load in Safari/Chrome.
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13473
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13474

No load event for embed (following a hyperlink): https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13476

<embed src="javascript:"> doesn't run the JS because it goes through fetch first.

Darn. I've asked @natechapin to see if we can understand Chromium's behavior better, and maybe find a more elegant solution inspired by that. But given what you've checked so far, this seems to be the best way forward.

An approach I considered was to check for javascript: URL in https://html.spec.whatwg.org/multipage/iframe-embed-object.html#process-the-iframe-attributes step 2.3 (which fires a load event for about:blank). But then lazy-loading wouldn't work (which it also doesn't in Chromium), which I think is surprising behavior.

I've added more tests now in web-platform-tests/wpt#50193

Nate has gone out of office, and we seem to have landed something that caused a merge conflict on this. But I'd still like to help get this landed.

I noticed from the WPT results that WebKit passes 100% of these tests. Combined with Gecko's interest, that should suffice to land this.

However, I'd still like to make a last-ditch attempt at figuring out a nicer way to spec this. @annevk, would you or someone else from WebKit (maybe @cdumez?) be able to tell us how WebKit manages to pass all the tests? Is it via some sort of special "fire the load event" flag like this PR does, or is there something more elegant that doesn't require threading through as many layers?

In FrameLoader::SubframeLoader::loadOrRedirectSubframe we have this

        if (upgradedRequestURL.protocolIsJavaScript()) {
            Ref ownerDocument = ownerElement.document();
            ownerDocument->incrementLoadEventDelayCount();
            stopDelayingLoadEvent = [ownerDocument = WTFMove(ownerDocument)] (ScheduleLocationChangeResult) {
                ownerDocument->decrementLoadEventDelayCount();
            };
        }

which seems more locally managed than this PR. I'm not super familiar with the entire setup however. Maybe @achristensen07 is.

Hmmm this is still incorrect. This PR says to fire 2 load events for https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13709 but Chromium and WebKit fire only 1.

Maybe load should only be fired if the current document is the initial about:blank document, and the navigation comes from "process the iframe attributes".

https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13712

Maybe also when initialInsertion is true, though that could be different between Chromium and WebKit.

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13711 gets 2 load events in chromium, 1 in webkit.

cc @EdgarChen

This should now more closely match WebKit and what @EdgarChen implemented in Gecko (bug).

Still need to rebase and add more tests.

Still need to add some more tests based on the Live DOM Viewer demos.

I've written the tests I was planning to and filed a chromium bug.