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?

(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.

Please re-assign the bug to me when there is something actionable for me. :-)

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".

This bug was cloned to create HTML WG bug 19062.

http://www.w3.org/mid/4DFC5AC4.7030105@gmail.com

Mykyta: Any news on this draft being updated?

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.

*** Bug 20990 has been marked as a duplicate of this bug. ***

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.

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...".

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.

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.

Fetch needs to react to javascript: by treating it as an invalid protocol.

Have to remember to set the override URL, still.

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

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?

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

> 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).

No, that sounds fine.  Thanks!

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).

Right, the url of javascript:-generated pages is something we need to sort through still; it's only tangentially related to the processing model.

*** Bug 19492 has been marked as a duplicate of this bug. ***