W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] URL: javascript URLs

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 28 Sep 2012 17:19:55 +0200
Message-ID: <CADnb78gvde7JLcbFJu0DDpMbPZ5DYHXbOUNjpvHEUaSCR14DXA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org
On Fri, Sep 28, 2012 at 4:52 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 9/28/12 7:45 AM, Anne van Kesteren wrote:
>> What I am wondering about is why e.g. %E2%84 results in a code point
>> in both Gecko and Chrome and whether that is required for
>> compatibility (in Opera I get U+FFFD as I expected).
>
> I'm not sure I follow.  javascript:alert("%E2%84".charCodeAt(0)) does the
> same thing for me in Gecko, Chrome, and Opera.  What are you testing,
> exactly?

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1809

Gives "â„" in Chrome (charCodeAt -> 226). I cannot get it to alert in
my Nightly (18.0a1 (2012-09-28), Mac), Opera yields one FFFD and
Safari two. So maybe this is less of a problem than I thought. Simply
convert to bytes, then decode as utf-8, then execute.


>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0317.html
>> but it appears no other browser has that.
>
> That was for treatment of the return value, not for figuring out the string
> to execute, right?

Thanks, makes more sense now :-)


> If you're trying to define behavior for various cases of javascript:, you
> should consider defining the following, to the extent that they're not
> already defined:
>
> 1)  Whether the script executes (compare <img src> vs <iframe src>),
>     but note that some UAs _do_ run the script for <img src>, but in
>     a sandbox).
> 2)  When the script evaluates (sync vs async, say).
> 3)  The global object the script evaluates against.
> 4)  The origin and effective script origin of the script.
> 5)  What happens when this doesn't match the origin or effective script
>     origin or whatever of the global object the script is evaluating
>     against.
> 6)  Interactions with sandboxed iframes and CSP.  What happens when
>     the parent page sets the location of a sandboxed iframe to a
>     javascript: URI, for example?  I would be slightly shocked if
>     there is UA interop here.
> 7)  Handling of the return value of the script.

I guess these are all up to HTML to define (and I think it does
already do all of these, perhaps with bugs in the CSP stuff). So I
should just define the path[0] + "#" + fragment -> bytes -> decode as
utf-8 -> script source algorithm for HTML to reference.

http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme does not
define more than that and even that it does a crappy job at currently.
:/


-- 
http://annevankesteren.nl/
Received on Friday, 28 September 2012 15:20:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC