13720 2011-08-10 02:56:04 +0000 Define javascript: processing entirely inline, and make it only happen in the navigation algorithm; then, remove special-casing elsewhere, and make it non-conforming in those places 2013-11-21 12:59:17 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#javascript-protocol P3 minor Unsorted 12986 1 mike ian annevk bzbarsky eoconnor evnikita2 ian julian.reschke mike public-html-admin public-html-wg-issue-tracking robin shadow2531 w3cbugzilla public-html-bugzilla oldest_to_newest 54553 0 mike 2011-08-10 02:56:04 +0000 > Probably the same is with 'javascript' URIs (Section 6.1.5). It > references [JSURL], the draft-hoehrmann-javascript-scheme, which is > now expired. It includes-by-reference the source code retrieval > operation for these URIs > (http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3.1). > I propose not to include it by reference but rather describe in the > specification itself. The algorithm contains only 4 steps so it > shouldn't be a problem. [split out from bug 12986] 54958 1 annevk 2011-08-14 09:44:24 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: Do you mean the HTML specification ought to define the javascript URL scheme fully? 54967 2 evnikita2 2011-08-14 10:09:34 +0000 (In reply to comment #1) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > <http://dev.w3.org/html5/decision-policy/decision-policy.html>. > > Status: Rejected > Change Description: no spec change > Rationale: Do you mean the HTML specification ought to define the javascript > URL scheme fully? Marked as REOPENED now. I need some time to contact Bjoern Hoehrmann, the author of this draft, to ask whether he's going to continue work on it; then I'll be able to answer. Please keep this bug open until there is any response from him. 55013 3 ian 2011-08-15 03:51:37 +0000 Please re-assign the bug to me when there is something actionable for me. :-) 55068 4 evnikita2 2011-08-15 10:22:33 +0000 I did finally receive the response from Bjoern. He claims he'll continue work on the draft; and I personally think this work will be performed by the time HTML5 will have reached W3C Recommendation level. I'll close the ticket as "LATER". 82021 5 public-rdfa-wg 2013-01-24 06:30:57 +0000 This bug was cloned to create HTML WG bug 19062. http://www.w3.org/mid/4DFC5AC4.7030105@gmail.com 84640 6 ian 2013-03-19 17:38:48 +0000 Mykyta: Any news on this draft being updated? 84642 7 annevk 2013-03-19 17:42:57 +0000 FWIW, I think we could define it inline using http://wiki.whatwg.org/wiki/URL_schemes#javascript:_URLs That might not be so bad given that we're only using it in the navigate algorithm. 85898 8 ian 2013-04-10 21:54:17 +0000 *** Bug 20990 has been marked as a duplicate of this bug. *** 85899 9 ian 2013-04-10 21:56:12 +0000 Ok. I think we'll just define it inline. Since we're moving towards doing it only during HTML navigation, there's not much point having a reusable spec. 95222 10 ian 2013-10-23 19:17:04 +0000 Ok so the plan here is to remove all occurrences of "javascript:" in the spec, and move all the normative content to the Navigate algorithm, to a branch in the step that says "If the new resource is to be fetched using HTTP GET or equivalent...". 95353 11 ian 2013-10-25 18:05:08 +0000 Said branch should avoid "fetch" entirely, and run JS directly. This fixes one bug which is that right now we try to execute javascript: async without a task, oops. We'll also have to change "Wait for one or more bytes to be available or for the user agent to establish that the resource in question is empty" in navigate. 95356 12 ian 2013-10-25 18:24:44 +0000 We do need this case to run the JS async, though: frame = document.createElement('iframe'); frame.src = 'javascript:alert(2);'; // alerts second document.body.appendChild(frame); alert(1); // alerts first Maybe queue a task to run the script, and have the "Wait for one or more bytes" step be ready to wait for bytes from either fetch or this JS deref task. 96346 13 ian 2013-11-14 22:25:30 +0000 Fetch needs to react to javascript: by treating it as an invalid protocol. 96347 14 ian 2013-11-14 22:34:20 +0000 Have to remember to set the override URL, still. 96358 15 contributor 2013-11-15 15:56:29 +0000 Checked in as WHATWG revision r8284. Check-in comment: Move javascript: processing entirely into HTML, and fix its definitions to match reality better at the same time. http://html5.org/tools/web-apps-tracker?from=8283&to=8284 96360 16 bzbarsky 2013-11-15 16:12:57 +0000 I'm having trouble following the changes, so I have some questions: 1) Does javascript: evaluation still affect session history after this change if it creates a new document? 2) Does javascript: still run async after this change in all cases? 96362 17 contributor 2013-11-15 16:18:40 +0000 Checked in as WHATWG revision r8285. Check-in comment: Define the task settings for the javascript: task http://html5.org/tools/web-apps-tracker?from=8284&to=8285 96382 18 ian 2013-11-15 20:27:56 +0000 > 1) Does javascript: evaluation still affect session history after this > change if it creates a new document? Yeah. All that's really replaced is that instead of calling "fetch" we evaluate a script and use its result as the resource's data, and there's a hack to fix the URL to the previous URL. > 2) Does javascript: still run async after this change in all cases? It runs in a separate task, if that's what you mean. (The previous state of the spec with respect to this question was nonsensical. It ran the script literally asynchronously, potentially in parallel with scripts running as part of tasks run in the event loop!) Please reopen the bug if there's anything else I should look at; I likely won't see changes to this bug for months if it's closed (I only look at bugmail every few weeks). 96383 19 bzbarsky 2013-11-15 20:30:09 +0000 No, that sounds fine. Thanks! 96387 20 ian 2013-11-15 20:56:50 +0000 FWIW, the spec (if I'm not missing something) matches the expectation of the test cases here: http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/ Note that Firefox doesn't quite match these; in particular, the spec, the tests, and Chrome/Safari never give a page a URL starting with the "javascript:" scheme. IE matches the tests except for 005, where it somehow gets the outer page URL instead of "about:blank" (not sure what's going on there). 96391 21 bzbarsky 2013-11-15 21:31:18 +0000 Right, the url of javascript:-generated pages is something we need to sort through still; it's only tangentially related to the processing model. 96637 22 annevk 2013-11-21 12:59:17 +0000 *** Bug 19492 has been marked as a duplicate of this bug. ***