javascript URLs that do not return strings is apparently wrong #1896

domenic · 2016-10-13T16:47:12Z

See @bzbarsky's comment at #1107 (comment).

@bzbarsky could you explain in more detail how the current spec is wrong? Is the idea that the response status should not be 204, and that it should have a Content-Type header, but it should still have the empty body?

bzbarsky · 2016-10-13T17:18:39Z

"wrong" is a slightly loaded term. What I will claim is that the current spec does not match non-Gecko UAs, which it claimed to do, and is not web-compatible.

The latter problem is described in in #1895

For the former, a quick check suggests that at least Chrome and Safari seem to convert non-string values to the string "" and then proceed to load that as the response body. They also treat exceptions in the javascript: as "". Here's the testcase I used:

<!DOCTYPE html>
<input type="button" value="Load javascript:undefined"
       onclick="doLoad('undefined')">
<input type="button" value="Load javascript:1"
       onclick="doLoad('1')">
<input type="button" value="Load javascript:false"
       onclick="doLoad('false')">
<input type="button" value="Load javascript:null"
       onclick="doLoad('null')">
<input type="button" value="Load javascript:new String(&quot;foo&quot;)"
       onclick="doLoad('new String(&quot;foo&quot;)')">
<input type="button" value="Load javascript:new Object()"
       onclick="doLoad('new Object()')">
<input type="button" value="Load javascript:&quot;bar&quot;"
       onclick="doLoad('&quot;bar&quot;')">
<input type="button" value="Load javascript:noSuchFunc()"
       onclick="doLoad('noSuchFunc()')">
<hr>
<script>
  function doLoad(arg) {
    document.querySelector("iframe").src = "javascript:"+arg;
  }
  var blob = new Blob(["Original document"], { type: "text/plain" });
  var url = URL.createObjectURL(blob);
  var ifr = document.createElement("iframe");
  ifr.src = url;
  ifr.name = "iframe";
  document.body.appendChild(ifr);
</script>

This is one possible thing that could be specified, and would not suffer from the problem described in #1895. It would not match longstanding IE/Gecko/Netscape behavior for undefined, of course.

I haven't tested what Chrome/Safari do in other cases of interest, like:

The origin check in https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol step 1 fails (iirc, that case is treated as 204 by them, but I didn't really test very carefully).
Script is disabled.
CSP blocks the execution (I actually have no clue where this is specified at all; certainly not in HTML or https://w3c.github.io/webappsec-csp/#script-src-inline; filed Interaction of CSP and javascript: URLs in iframe src is not defined anywhere w3c/webappsec-csp#127 on it).

or whatever other cases currently get commoned up into the "return value is not string" codepath.

bzbarsky · 2016-10-13T17:20:03Z

Oh, and the point is that the "script is disabled" and "CSP blocks the execution" cases can still have it be observable whether the load event fires, so the interaction there would need to be specified not matter what, even if we take the Blink/WebKit approach for the cases in the testcase I pasted above.

domenic · 2016-10-13T17:21:36Z

For the former, a quick check suggests that at least Chrome and Safari seem to convert non-string values to the string "" and then proceed to load that as the response body. They also treat exceptions in the javascript: as "". Here's the testcase I used:

What I don't understand is why this is different from the current spec, which says

Process result: If Type(result) is not String, then set response to a response whose status is 204.

Run process a navigate response with resource, response, navigationType, the source browsing context, and browsingContext, and then abort these steps.

I'm probably just missing something, but that's the largest source of my confusion.

domenic · 2016-10-13T17:22:07Z

Oh, duh, it's because 204s abort in the next algorithm. I get it, sorry.

bzbarsky · 2016-10-13T17:22:53Z

Oh, duh, it's because 204s abort in the next algorithm.

Right, exactly.

See whatwg/html#1896.

domenic · 2016-10-15T00:15:04Z

OK, here is the problem. Your test case, with loading things into iframe srcs, shows that they do process the response bodies as empty strings. But the following test case shows that they don't, when clicking on <a> elements: https://jsbin.com/zokamoyoxe/edit?html,output

I don't really know what to make of this. Is this distinction make elsewhere in navigation? How do Blink and WebKit actually implement this!?

DO NOT MERGE until we settle #1896; see #1896 (comment).

bzbarsky · 2016-10-15T02:23:31Z

I don't really know what to make of this.

Well. See my (somewhat lazy, not backed by testing) comments about "not-initial javascript: loads" in #1895 (comment). But of course my testcase in this bug also has non-initial loads.

How do Blink and WebKit actually implement this!?

Last I looked, really crazily. ;) Starting with "not in navigation, unlike the spec". That's mostly what you can make of this.

Is this distinction make elsewhere in navigation?

Not particularly, no.

Note that it's worth testing what location.href sets do as well; those may have yet another behavior. Or maybe we're lucky and they match anchor clicks.

One piece of good news is that for web compat purposes we don't need to duplicate WebKit/Blink here in general.... The problem is that we're not sure what a saner web-compatible behavior is, apart from the current Firefox or Edge ones (which are different, note; I have no idea what Edge really does!).

domenic · 2016-10-15T02:25:52Z

At this point I'm leaning toward the current Firefox behavior, as it sounds rather easy to spec. But I feel like I should probably do more research and testing and noodling over the spec to see what variations would be less invasive...

domenic · 2016-10-15T19:36:21Z

Does using javascript: URLs in the following ways cause navigation? A per-browser breakdown.

javascript: URL usage	Edge	Chrome	Firefox	Safari
`location.href` assignment (non-string)				?
`location.href` assignment (string)	X	X	X	?
Clicking an `<a>` (non-string)				?
Clicking an `<a>` (string)	X	X	X	?
`iframe.src` assignment (non-string)		X		?
`iframe.src` assignment (string)	X	X	X	?

Leaving Safari as ?s since I don't have my Safari tech preview computer for the weekend, but my guess is it's going to be the same as Chrome.

I might have gotten turned around, but this implies that Edge and Firefox are compatible with the current spec. But @bzbarsky, you say that that's not web-compatible? Despite Edge and Firefox shipping it to stable?

bzbarsky · 2016-10-15T21:05:12Z

The main web compat requirement I'm aware of for the non-string case is this:

<iframe src="javascript:non-string-non-undefined"></iframe>

needs to fire a load event. Certainly when non-string-non-undefined is a boolean false, because the jQuery fileupload library relies on that, but possibly in other cases too; I didn't carefully analyze all the sites that had this problem. Note that this says nothing about whether a navigation happens; I haven't tested that carefully, not least because it's not trivial to detect given that UAs disagree with the spec in various other ways around javascript: URLs in general (e.g. what the URL of the document resulting from the navigation is). We could add tests for this, of course.

In terms of what's shipped, Firefox until Firefox 49 fired the load event in that situation for non-undefined return values, because it did a navigation (to the ToString() of the return value). Firefox 49 aligned with the spec, which does NOT fire a load event in that situation, and this broke a bunch of websites; we did not get any bug reports until shipping to stable because all the sites involved require an account and we didn't have any pre-release users with accounts on those sites who noticed the issue, apparently. :( We're likely to do a point release of Firefox 49 soon, backing out my change to align with the current spec. All the non-release branches have already been updated with the backout.

As for Edge, I have verified that it does fire a load event in the case of:

<iframe src="javascript:false"></iframe>

but I have not investigated in detail whether it performs a navigation or not, in that situation and others; testing Edge on my end is a bit of a pain.

bzbarsky · 2016-10-15T21:10:27Z

So to be clear, the known-web-compatible "Firefox behavior" is not found in current release Firefox 49, nor in Firefox nightlies from a few days ago (before the backout). You can see it in a nightly from 2016-10-15 (today), though.

bzbarsky · 2016-10-15T21:11:01Z

And note that "non-string" in the Firefox behavior contains two buckets that have different behaviors: there's undefined and everything else.

annevk · 2017-07-27T12:42:10Z

When exactly does <iframe src="javascript:false"></iframe> need to fire a load event? Does <iframe>.src = "javascript:false" at some arbitrary point in time also need to cause a load event? (That is, could it just be the load event from creating and appending the iframe element, assuming we ever start doing that consistently for about:blank.)

bzbarsky · 2017-07-28T20:41:56Z

When exactly does <iframe src="javascript:false"></iframe> need to fire a load event?

Unclear. The failure symptoms on the web were that if it never fired one, sites would "hang" because they were waiting for that event to do other stuff.

https://bugzilla.mozilla.org/show_bug.cgi?id=1307420#c9 has a quote of the relevant jQuery plugin code. You may be able to find other information in https://bugzilla.mozilla.org/show_bug.cgi?id=1306472 and its various duplicates...

It's possible that treating this load as a 204 but still firing a load event like we would for no src at all or src="about:blank" might be good enough. I just can't tell you.

Does <iframe>.src = "javascript:false" at some arbitrary point in time also need to cause a load event?

Unknown. Worth checking whether it does in browsers.

annevk · 2017-07-31T11:43:32Z

<!DOCTYPE html>
<script>w("before iframe")</script>
<iframe onload=w('load') src=javascript:false></iframe>
<script>w("after iframe")</script>

With w() logging ends up as before iframe, after iframe, load in Edge and Firefox and before iframe, load, after iframe in Chrome and Safari TP.

<!DOCTYPE html>
<iframe onload=w('load')></iframe>
<script>
setTimeout(() => {
  w("timeout")
  document.querySelector("iframe").src = "javascript:false"
  w("after src")
}, 200)
</script>

Ends up as load, timeout, after src, load in all browsers, except Edge doesn't log the final load.

bzbarsky · 2017-07-31T14:07:59Z

As far as Chrome and Safari go, they do weird sync stuff with javascript: even in the string case. Most simply:

<!DOCTYPE html>
<script>w("before iframe")</script>
<iframe onload=w('load') src=javascript:"hello"></iframe>
<script>w("after iframe")</script>

logs: before iframe, load, load (yes, twice), after iframe in Chrome and Safari.

Also note that this testcase:

<!DOCTYPE html>
<iframe onload=w('load') src="javascript:'Does this stick around?'"></iframe>
<script>
setTimeout(() => {
  w("timeout")
  document.querySelector("iframe").src = "javascript:false"
  w("after src")
}, 2000)
</script>

shows that the load of false is not treated as a 204 in Chrome and Safari at all: it makes the previous document go away instead. Same thing if I use http://software.hixie.ch/utilities/ for the src. Similar for:

<!DOCTYPE html>
<iframe onload=w('load') src="javascript:'Does this stick around?'"></iframe>
<script>
setTimeout(() => {
  w("timeout")
  document.querySelector("iframe").src = "javascript:undefined"
  w("after src")
}, 2000)
</script>

though that one is treated as a 204 in Firefox and Edge.

annevk · 2017-07-31T14:12:21Z

I'd be okay with just loading an empty 200. I guess effectively treating them as navigating to about:blank?

bzbarsky · 2017-07-31T14:16:18Z

I guess we have no indication that "sync stuff happens" based on those testcases, as opposed to "iframe with javascript: src blocks the parser until its src runs". But this testcase:

<!DOCTYPE html>
<script>
  w("before iframe");
  var i = document.createElement("iframe");
  i.setAttribute("onload", "w('load')");
  i.src = "javascript:'hello'";
  document.documentElement.appendChild(i);
  w("after iframe");
</script>

shows that it really is "sync stuff happens", complete with the two firings of onload.

I'd be okay with just loading an empty 200

For which cases?

I guess effectively treating them as navigating to about:blank?

Whatever cases these are, why not just treat them as if the javascript: returned "" for simplicity, instead of having to shoehorn about:blank in there?

Note that I did point out some of these aspects of the behavior in #1896 (comment) along with my list of things that still need testing...

bzbarsky · 2018-07-18T15:29:41Z

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1382035 there is now a web-compat requirement that <a href="javascript: foo()"> not perform navigation when foo returns a Promise. Per the table above, this is something Chrome already does for <a> but not <iframe>. It's not something Firefox does, but due to the web compat issues we are running into we will be adding a special-case for Promise return values specifically in our javascript: handling.

It would be good to get this thing sorted out, given that it's causing real-life compat pain. @domenic can Chrome align closer to the spec for its javascript: handling, or failing that create good documentation for what it's actually doing?

domenic · 2018-08-01T21:16:57Z

:(

I can ask around about aligning Chrome closer to the spec, although it sounds like the spec is not web-compatible and we'd need to work on a better spec first. I haven't had time for that myself; again I can ask around, but perhaps Mozilla could help?

As for Chrome creating documentation on what we're doing, again I can ask around. I suppose Chrome engineers are better positioned to read their source code and transcribe it into prose than other folks would be...

bzbarsky · 2018-08-01T21:29:17Z

The part of the spec that is not web-compatible is the load event behavior, not the handling of javascript: per se, for what it's worth.

bzbarsky · 2018-08-01T21:30:14Z

But in general, I can obviously spec what Firefox does, say. The question is whether Chrome would be willing to implement it. If not, what are the constraints on what Chrome is willing to implement?

domenic · 2018-08-01T21:33:01Z

Hmm I guess I don't understand the load event connection, but maybe I need to page more of this area/thread into my memory.

I know @zetafunction was looking in to modernizing Chrome's javascript: handling, specifically wanting to make it async, in #3730. That does indeed point to some constraints, or at least wishes. Let me try to get him specifically to chime in.

bzbarsky · 2018-08-01T21:34:17Z

The load event connection is described in #1895

zetafunction · 2018-08-01T22:56:37Z

I think we're willing to implement what Firefox specs. Unfortunately, there's a lot of things that are broken about javascript: URLs in Chrome. From my perspective, the two things we should fix first are:

run the Javascript URL processing steps asynchronously
the double load event (I have no idea why this is happening without digging in more; is there a bug already filed for this?)

@bzbarsky Am I correct in understanding that Firefox matches the spec queues a task to run the javascript: URL steps in https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol? I'd like to make sure that any changes we make here bring us closer to the spec and Firefox.

bzbarsky · 2018-08-02T18:49:27Z

So generally speaking, what Firefox implements aims to match the current spec, with to my knowledge two exceptions. One is what the final URL of a javascript: navigation is, and we are planning to align to the spec on that. The other is that https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol step 12 is instead:

If IsPromise(result) is true, then set result to undefined.
If Type(result) is not Undefined, set result to ToString(result). If that throws an exception, report the exception and set result to undefined.
If Type(result) is Undefined, then set response to a response whose status is 204. Otherwise, ... (what the spec has in its step 12, since at this point we know result is a string).

There might be some complications around the exception-reporting part in terms of sync vs async.

foolip · 2018-08-16T16:04:46Z

@zetafunction do we have an open issue for "run the Javascript URL processing steps asynchronously"? It looks to at a glance like nothing in https://wpt.fyi/results/html/browsers/browsing-the-web/navigating-across-documents is targeting this behavior, does anyone know if there are other tests for it? @bzbarsky, perhaps in Gecko?

domenic · 2018-08-16T16:17:59Z

We have #3730 but last I asked @zetafunction he said that @annevk convinced him that was not the right way to go. If so maybe closing that one and opening a new one more targeted at javascript: URLs would be helpful.

foolip · 2018-08-16T17:23:43Z

I was thinking of an issue on crbug.com, but sounds like any change is still blocked on some spec changes?

domenic self-assigned this Oct 15, 2016

domenic added a commit to web-platform-tests/wpt that referenced this issue Oct 15, 2016

Update javascript: URL return value tests

9505707

See whatwg/html#1896.

domenic mentioned this issue Oct 15, 2016

Update javascript: URL return value tests web-platform-tests/wpt#3981

Open

domenic added a commit to web-platform-tests/wpt that referenced this issue Oct 15, 2016

Update javascript: URL return value tests

886a7ba

See whatwg/html#1896.

domenic added a commit that referenced this issue Oct 15, 2016

Change javascript: URL processing to use empty body instead of 204

aecbdc7

DO NOT MERGE until we settle #1896; see #1896 (comment).

domenic mentioned this issue Oct 15, 2016

Change javascript: URL processing to use empty body instead of 204 #1904

Open

domenic mentioned this issue Apr 26, 2017

javascript URL: interaction with abort is not web-compatible #2590

Open

annevk changed the title ~~javascript: URLs that do not return strings is apparently wrong~~ javascript URLs that do not return strings is apparently wrong Jul 27, 2017

annevk added the topic: navigation label Jan 22, 2018

domenic added the topic: javascript: URLs label Jun 15, 2018

foolip added compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other labels Aug 1, 2018

annevk mentioned this issue Jun 23, 2021

How javascript URLs interact with session history #6798

Closed

whatwg deleted a comment Oct 25, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

javascript URLs that do not return strings is apparently wrong #1896

javascript URLs that do not return strings is apparently wrong #1896

domenic commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

domenic commented Oct 13, 2016

domenic commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

domenic commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

domenic commented Oct 15, 2016

domenic commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

annevk commented Jul 27, 2017 •

edited

Loading

bzbarsky commented Jul 28, 2017

annevk commented Jul 31, 2017

bzbarsky commented Jul 31, 2017

annevk commented Jul 31, 2017

bzbarsky commented Jul 31, 2017

bzbarsky commented Jul 18, 2018

domenic commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

domenic commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

zetafunction commented Aug 1, 2018

bzbarsky commented Aug 2, 2018

foolip commented Aug 16, 2018

domenic commented Aug 16, 2018

foolip commented Aug 16, 2018

javascript URLs that do not return strings is apparently wrong #1896

javascript URLs that do not return strings is apparently wrong #1896

Comments

domenic commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

domenic commented Oct 13, 2016

domenic commented Oct 13, 2016

bzbarsky commented Oct 13, 2016

domenic commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

domenic commented Oct 15, 2016

domenic commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

bzbarsky commented Oct 15, 2016

annevk commented Jul 27, 2017 • edited Loading

bzbarsky commented Jul 28, 2017

annevk commented Jul 31, 2017

bzbarsky commented Jul 31, 2017

annevk commented Jul 31, 2017

bzbarsky commented Jul 31, 2017

bzbarsky commented Jul 18, 2018

domenic commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

domenic commented Aug 1, 2018

bzbarsky commented Aug 1, 2018

zetafunction commented Aug 1, 2018

bzbarsky commented Aug 2, 2018

foolip commented Aug 16, 2018

domenic commented Aug 16, 2018

foolip commented Aug 16, 2018

annevk commented Jul 27, 2017 •

edited

Loading