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.

Sign up for GitHub

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

Jump to bottom

Iframe with initial javascript: source needs to fire the load event in various cases #1895

Open
bzbarsky opened this issue Oct 13, 2016 · 7 comments · May be fixed by #10957
Open

Iframe with initial javascript: source needs to fire the load event in various cases #1895

bzbarsky opened this issue Oct 13, 2016 · 7 comments · May be fixed by #10957
Assignees
@annevk
Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: javascript: URLs topic: navigation

Comments

@bzbarsky
Copy link
Contributor

bzbarsky commented Oct 13, 2016 •
edited
Loading

Consider this testcase:

<iframe src="javascript:true" onload="alert('event fired')"></iframe>

Until recently, this fired the load even in all browsers. When Firefox changed to not firing the load event here (following the current spec), we encountered breakage in websites: there are sites that run javascript: URLs that return booleans in frames and wait for the load event before doing something else [1]. Note that Firefox never fired a load event in this situation for the "javascript:undefined" case, but other browsers do.

The current state of this in the spec is as follows:

  1. Start at https://html.spec.whatwg.org/multipage/embedded-content.html#process-the-iframe-attributes
  2. No srcdoc attr, have an src attr, so go to https://html.spec.whatwg.org/multipage/embedded-content.html#otherwise-steps-for-iframe-or-frame-elements
  3. Step 4 lands in https://html.spec.whatwg.org/multipage/browsers.html#navigate
  4. We enter the parallel section of navigation.
  5. The request's url's scheme is "javascript", so we queue a task to run https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol
  6. In step 11 the response is set to a 204 response, since the return value is not a String.
  7. In step 12 we go to https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-response
  8. In step 2 the steps are aborted.

I don't see anything in the spec right now that would fire a load event in this situation. There presumably needs to be something.

Of course not-initial javascript: loads that return a boolean shouldn't fire a load event (or should it? I haven't tested non-Firefox browsers here), which adds to the fun of the whole thing.

[1] For example, the jQuery fileupload library does this. See https://bugzilla.mozilla.org/show_bug.cgi?id=1307420#c9 but chances are all the duplicates of https://bugzilla.mozilla.org/show_bug.cgi?id=1306472 will have similar issues on their sites.
@bzbarsky bzbarsky mentioned this issue Oct 13, 2016
Merged
@bzbarsky
Copy link
Contributor Author

Once this is sorted out, the html/browsers/browsing-the-web/navigating-across-documents/javascript-url-return-value-handling.html web platform test should be updated accordingly. I'm going to mostly disable it for now, because the thing it's testing is, while matching the spec, not web-compatible.

@bzbarsky bzbarsky mentioned this issue Oct 13, 2016
Open
@zcorpan
Copy link
Member

zcorpan commented Dec 5, 2024

For <iframe src="javascript:true"></iframe>, the spec currently says to do nothing, but Chrome and Safari navigate to about:blank (and fire load). Gecko navigates to the document "true".

https://html.spec.whatwg.org/#process-the-iframe-attributes step 2.7 calls
https://html.spec.whatwg.org/#navigate-an-iframe-or-frame step 4 calls
https://html.spec.whatwg.org/#navigate step 20.1 queues a task that calls
https://html.spec.whatwg.org/#navigate-to-a-javascript:-url step 6 calls
https://html.spec.whatwg.org/#evaluate-a-javascript:-url which says

If evaluationStatus is a normal completion, and evaluationStatus.[[Value]] is a String, then set result to evaluationStatus.[[Value]].

Otherwise, return null.

The caller https://html.spec.whatwg.org/#navigate-to-a-javascript:-url step 7 says

If newDocument is null, then return.

Gecko needs to match WebKit/Chromium for web compat (see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1931058).

From reading the spec, possibly navigate step 20.2 could check the result of the javascript: navigation, and continue the navigate steps with about:blank instead of returning. But what actually happens in WebKit or Chromium?

@zcorpan zcorpan added the compat Standard is not web compatible or proprietary feature needs standardizing label Dec 5, 2024
@domenic
Copy link
Member

domenic commented Dec 6, 2024

but Chrome and Safari navigate to about:blank (and fire load).

Probably the most important question is, do they navigate to a non-initial about:blank, or do they just fire load on the initial about:blank?

But what actually happens in WebKit or Chromium?

@natechapin may be able to help us with the Chromium behavior. Maybe @rwlbuis or @cdumez for WebKit?

@natechapin
Copy link

but Chrome and Safari navigate to about:blank (and fire load).

Probably the most important question is, do they navigate to a non-initial about:blank, or do they just fire load on the initial about:blank?

But what actually happens in WebKit or Chromium?

@natechapin may be able to help us with the Chromium behavior. Maybe @rwlbuis or @cdumez for WebKit?

When chromium fires the load event, it's still the initial about:blank in the state machine.

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Jan 21, 2025
@zcorpan
HTML: test <iframe src=javascript:...>
65c9e5d 
Test different return types, whether it is stringified and parsed and how many load events are fired.

See whatwg/html#1895
@zcorpan zcorpan mentioned this issue Jan 21, 2025
Open
@zcorpan
Copy link
Member

zcorpan commented Jan 21, 2025

I've created a PR with tests here: web-platform-tests/wpt#50193

I'm still not sure how to change the spec so that it fires a load event when the src is a javascript: URL that returns a non-string.

@zcorpan
Copy link
Member

zcorpan commented Jan 21, 2025

Here's an interesting case with different behavior in Chrome (alert) vs Safari/Firefox (no alert)

<iframe src="javascript:alert(1)" hidden loading=lazy>

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

zcorpan added a commit that referenced this issue Jan 28, 2025
@zcorpan
Fire a load event for javascript: URL non-strings
b1916b3 
Fixes #1895.
@zcorpan zcorpan linked a pull request Jan 28, 2025 that will close this issue
Open
6 tasks
@zcorpan
Copy link
Member

zcorpan commented Jan 28, 2025 •
edited
Loading

I think making loading=lazy "work" for javascript: URLs (like Safari) makes more sense.

As far as I can tell, firing a load event here will do the trick:

https://html.spec.whatwg.org/#evaluate-a-javascript:-url step 10

Otherwise, return null.

PR: #10957

However, this still maybe isn't quite right. Details in the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@annevk annevk

Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: javascript: URLs topic: navigation
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fire a load event for javascript: URL non-strings whatwg/html
5 participants
@zcorpan @domenic @bzbarsky @annevk @natechapin