what does IE do on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1760 ?

WebKit runs the script but appears to discard the results.
Opera and Gecko seem to just not run the script.

Based on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1762 it looks like Gecko is just never bothering to follow the link. This is consistent with the submission navigation being started async and immediately canceling the hyperlink navigation; javascript: is thus not special for Gecko. Opera and WebKit seem to follow the spec for that case, so javascript: is special for them.

Would love to know what IE is doing here.

(In reply to comment #1)
> what does IE do on
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1760 ?

Looks like IE runs the javascript url, navigates to the javascript URL and then navigates to the form submission URL.

> WebKit runs the script but appears to discard the results.
> Opera and Gecko seem to just not run the script.
> 
> Based on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1762

This test doesn't really work in IE due to broken data url handling.

Would anyone object to us just making .submit() queue a task to do its work?

Does that fix the issue? It seems that normal navigations actually work the same way as form submissions: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1774

Guess there's no getting away from making javascript: magical somehow then. Maybe the same way as frag IDs, except don't run the JS?

More tests (they don't add anything that wasn't said above):
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1956
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1957
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1962

A more interesting test:
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1958

That last test shows a difference between Opera and Gecko. Gecko seems to special-case javascript: in links, but otherwise treats it normally. Opera, however, seems to ignore a second *JS-initiated* navigation entirely, regardless of what it is.

WebKit seems to never navigate to the return value of a javascript: link, it just acts like it always returns HTTP 204.

I didn't test IE myself, but what comment 2 above suggests that it just runs both navigations in parallel, or something.

More interesting tests:
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1965
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1966
  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1967

For WebKit, this is consistent with doing what the spec says except for acting like javascript: always returns 204. (Also, it doesn't abort running navigations.)

For Gecko, the first test is consistent with it not running javascript: links when a navigation is in process, but the second test shows that's not right... looks like it's more that javascript: isn't followed if there's a document.location navigation going on. Though the third tests suggests it's not that simple either. Maybe it's something like "if the current task has already set location"?

Opera is consistent with what I said above, about it not allowing a second JS-initiated navigation regardless of source.

So basically none of the browsers do anything sane.

Assuming we want to support javascript: return values, we can't do what that but otherwise do what WebKit does, because that doesn't match any UAs and ends up at the wrong page.

Opera seems to be off alone in doing something weird with JS-triggered navigations; I'm not comfortable with that level of magic.

IE, insofar as it has been tested here, runs multiple navigations, and I don't even _know_ what that means.

So we're left with doing what Gecko does, but I can't work what that is exactly.

bz, any chance you know what Gecko is doing here?

We don't do any special-casing of javascript: in links, that I know of.  Why do you think we do?

> WebKit seems to never navigate to the return value of a javascript: link

Yep.  They special-case <(i)frame src="javascript:">, basically.

On your "more interesting tests", here's what happens in Gecko:

>  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1965

The button's click event starts a navigation.  Then the javascript: runs, and starts _another_ navigation from the location set it does; this cancels both the already-pending navigation to 'document' and the pending navigation to the return value of 'javascript:', if any.  Note that the log shows both "JS handler ran" and "JS URL ran", so I'm not sure how you concluded something about not running javascript: links.

>  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1966

Starts a navigation to 'document', then runs the javascript: which starts a navigation to '/', which cancels everything else that's going on, just like in the previous test.

>  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1967

I'm not sure what the steps to reproduce are for this testcase...

> bz, any chance you know what Gecko is doing here?

I believe the summary of Gecko behavior around this stuff is as follows:

1)  When a javascript: load starts, we don't immediately start a navigation
    (hence don't do the normal "stop other things" behavior).
2)  If the return value is not "undefined", we start a navigation to that
    return value if the load has not been stopped in the meantime.
3)  The "stop other things" behavior when a navigation starts stops javascript:
    loads too.  If a navigation starts between when the javascript: load starts
    and when the script would actually run, the script does not run (because
    the javascript: load gets stopped).
4)  Clicking a link doesn't start the load of the href immediately in Gecko: it
    grabs some metadata from the link (target, URI, etc) and then posts an
    event to start the load.  So if your script calls click() on a javascript:
    link and then immediately sets location, that javascript: will still run. 
    Note that we could possibly change this to cancel the event when a
    navigation starts; would have to check compat issues.

Again, there is no special-casing of the specific case of "link to javascript:" anywhere here, apart from what follows from the separate special-casings for "javascript:" and "link" above.  ;)

Ok so #4 explains the original test's behaviour.

That's relatively straight-forward for us to do, I guess. Would people be ok with that? It's just making hyperlink navigation start the navigate algorithm asynchronously instead of the top bit of the navigate being synchronous as now. It limits the magic quite a lot.

Checked in as WHATWG revision r7794.
Check-in comment: Rewrite the link following stuff to better match reality.
http://html5.org/tools/web-apps-tracker?from=7793&to=7794