18854 2012-09-12 09:40:50 +0000 Make hyperlink navigation from clicking links asynchronously start /navigate/ rather than being synchronous as now 2013-04-08 20:41:40 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#navigate P3 normal Unsorted 1 contributor ian bzbarsky ian james mike contributor oldest_to_newest 73692 0 contributor 2012-09-12 09:40:50 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#navigate Complete: http://www.whatwg.org/c#navigate Comment: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1759 seems to be a special case where navigating to a javascript URL should not affect the existing navigation Posted from: 2001:4c28:a030:30:c9a:9910:b30b:8b12 User agent: Opera/9.80 (X11; Linux x86_64; Edition Next) Presto/2.12.378 Version/12.50 73706 1 ian 2012-09-12 17:41:06 +0000 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. 73764 2 james 2012-09-13 12:41:39 +0000 (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. 74014 3 ian 2012-09-17 21:32:59 +0000 Would anyone object to us just making .submit() queue a task to do its work? 74019 4 james 2012-09-18 07:43:42 +0000 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 74060 5 ian 2012-09-18 23:54:24 +0000 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? 79226 6 ian 2012-12-01 03:02:58 +0000 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? 79227 7 bzbarsky 2012-12-01 03:54:57 +0000 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. ;) 83062 8 ian 2013-02-12 23:03:56 +0000 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. 85736 9 contributor 2013-04-08 20:41:40 +0000 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