This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13720 - 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
Summary: Define javascript: processing entirely inline, and make it only happen in the...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P3 minor
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
: 19492 20990 (view as bug list)
Depends on:
Blocks: 12986
  Show dependency treegraph
 
Reported: 2011-08-10 02:56 UTC by Michael[tm] Smith
Modified: 2013-11-21 12:59 UTC (History)
12 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2011-08-10 02:56:04 UTC
> 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]
Comment 1 Anne 2011-08-14 09:44:24 UTC
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?
Comment 2 Mykyta Yevstifeyev 2011-08-14 10:09:34 UTC
(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.
Comment 3 Ian 'Hixie' Hickson 2011-08-15 03:51:37 UTC
Please re-assign the bug to me when there is something actionable for me. :-)
Comment 4 Mykyta Yevstifeyev 2011-08-15 10:22:33 UTC
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".
Comment 5 public-rdfa-wg 2013-01-24 06:30:57 UTC
This bug was cloned to create HTML WG bug 19062.

http://www.w3.org/mid/4DFC5AC4.7030105@gmail.com
Comment 6 Ian 'Hixie' Hickson 2013-03-19 17:38:48 UTC
Mykyta: Any news on this draft being updated?
Comment 7 Anne 2013-03-19 17:42:57 UTC
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.
Comment 8 Ian 'Hixie' Hickson 2013-04-10 21:54:17 UTC
*** Bug 20990 has been marked as a duplicate of this bug. ***
Comment 9 Ian 'Hixie' Hickson 2013-04-10 21:56:12 UTC
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.
Comment 10 Ian 'Hixie' Hickson 2013-10-23 19:17:04 UTC
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...".
Comment 11 Ian 'Hixie' Hickson 2013-10-25 18:05:08 UTC
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.
Comment 12 Ian 'Hixie' Hickson 2013-10-25 18:24:44 UTC
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.
Comment 13 Ian 'Hixie' Hickson 2013-11-14 22:25:30 UTC
Fetch needs to react to javascript: by treating it as an invalid protocol.
Comment 14 Ian 'Hixie' Hickson 2013-11-14 22:34:20 UTC
Have to remember to set the override URL, still.
Comment 15 contributor 2013-11-15 15:56:29 UTC
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
Comment 16 Boris Zbarsky 2013-11-15 16:12:57 UTC
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?
Comment 17 contributor 2013-11-15 16:18:40 UTC
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
Comment 18 Ian 'Hixie' Hickson 2013-11-15 20:27:56 UTC
> 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).
Comment 19 Boris Zbarsky 2013-11-15 20:30:09 UTC
No, that sounds fine.  Thanks!
Comment 20 Ian 'Hixie' Hickson 2013-11-15 20:56:50 UTC
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).
Comment 21 Boris Zbarsky 2013-11-15 21:31:18 UTC
Right, the url of javascript:-generated pages is something we need to sort through still; it's only tangentially related to the processing model.
Comment 22 Anne 2013-11-21 12:59:17 UTC
*** Bug 19492 has been marked as a duplicate of this bug. ***