107524 - javascript: URL encoding inconsistent

Status: VERIFIED DUPLICATE of bug 104081

(Core :: Networking, defect)

Description

[Dave Evans]

Consider the URL: javascript:alert('%41')

Is the script to be URL-decoded prior to processing or not?  i.e. does activation of the above URL alert an "A" or "%41" ?

Mozilla 0.9.5 currently alerts "%41" but shows "javascript:alert('A')" in the status bar.  Opera 5.12 does the same.  IE 5.5 shows, and does, alert('A').

I'm not sure as to whether the script fragment should be subject to URL encoding/decoding or not; if it is, then here is a bug (because it is not being URL-decoded prior to processing); if it is not, then here is a minor inconsistency (because the status bar does not reflect what will actually happen).

Comment 1

[Cormac F]

Can't find a dupe so marking NEW and sending to JavaScript Engine

Comment 2

[Cormac F]

Changing to NEW now. Sorry for the spam!

Comment 3

[Phil Schwartau]

DOM escape() function supersedes the JS Engine escape(). But as far
as the URL encoding goes, I think it is the Networking component that
is responsible. Reassigning to Networking for further triage - 

Comment 4

[Phil Schwartau]

I don't know if this helps any, but try this in the URL bar

       javascript: alert('%41'); alert(unescape('%41'));


You get '%41', then 'A'. So the unescape() is working fine.
The question this bug seems to ask is, "Should unescape() be 
automatically applied to every string in a javascript:URL ?"

I think you have to be careful: what if the javascript:URL
is trying to execute a script? It is acceptable in the JavaScript
language to use the literal string value '%41'. Would it be
right to go through such code and change every '%41' to an 'A'?

In pure JavaScript, the string '\u0041' gets converted to an 'A'.
That is how Unicode escape sequences are done in the language 
itself...

Comment 5

[Dave Evans]

> The question this bug seems to ask is, "Should unescape() be
> automatically applied to every string in a javascript:URL ?"

I don't think you can unescape *parts* of the Javascript code: the way I see
it, either the URL has got to be

  "javascript" ":" fragment-of-javascript-code

(thus, feed the fragment directly to the Javascript engine);
or, it's

  "javascript" ":" escape()d-fragment-of-javascript-code

(thus, unescape() the fragment, then feed the results to the Javascript engine).

Comment 6

[timeless]

javascript: is a non standardized protocol.

ie does evil magic. if you enter 
javascript:"<plaintext><a
onmouseover='window.status=(\"\t\")'>b</a></plaintext><b>hi</b>"

it helpfully escapes it to:
javascript:"<plaintext><a%20onmouseover='window.status=(\"\t\")'>b</a></plaintext><b>hi</b>"
before evaluating it. it then unescapes it before evaluation.
otoh mozilla uses data: for stuff like that, not javascript:"string" so ...

since there's no standard we have to support i think we can close this :)

Comment 7

[benc]

(thanks for the simplified testcase, the other bugs were a pain to understand
for a JS novice...)

The answer to your question: URLs do need to be escape encoded properly, which
we do now.

*** This bug has been marked as a duplicate of 104081 ***

Comment 8

[benc]

phil: my javascript knowledge is modest. can you verify this bug if you concur
it is a duplicate?

Comment 9

[Phil Schwartau]

Verified Duplicate. Note the original report above:

> Consider the URL: javascript:alert('%41')

> Is the script to be URL-decoded prior to processing or not? 
> i.e. does activation of the above URL alert an "A" or "%41" ?

> Mozilla 0.9.5 currently alerts "%41" 


Since bug 104081 was fixed, we now get "A" instead:

                              alerts
    javascript:alert('%41')  --------> "A"


We are now properly unescaping every javascript:URL before
handing it off to the JavaScript Engine. This same behavior
can be viewed in the standalone JavaScript shell if one
explicitly calls the unescape() function:

js> unescape('%41');
A