Fire a load event for javascript: URL non-strings

[zcorpan]

Fixes #1895.

• At least two implementers are interested (and none opposed):
  • Gecko
  • …
• Tests are written and can be reviewed and commented upon at:
  • HTML: test <iframe src=javascript:...> web-platform-tests/wpt#50193
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1931058
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/iframe-embed-object.html ( diff )

[zcorpan]

• 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.

[domenic]

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

[domenic]

I guess the end result here is fine, but the spec is so ugly 😅. I wonder how this is implemented in WebKit and Blink, and if it is similarly ugly or if it falls out more naturally in some way?

One idea would be that instead of passing a parameter to navigate, you always check if the "navigate to a javascript: URL" is being performed in a child navigable, and if so, fire the event on the navigable container? That would be different than this in that:

• It would also fire load events for embed and object
• It would also fire if code did iframe.contentWindow.location.href = "javascript:undefined"

Maybe writing tests for those scenarios would be instructive?

[zcorpan]

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.

[domenic]

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.

[zcorpan]

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.

[zcorpan]

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

[domenic]

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?