Anne van Kesteren
annevk at annevk.nl
Fri Sep 28 08:19:55 PDT 2012
On Fri, Sep 28, 2012 at 4:52 PM, Boris Zbarsky <bzbarsky at 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).
> same thing for me in Gecko, Chrome, and Opera. What are you testing,
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.
>> 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 :-)
> 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
> 6) Interactions with sandboxed iframes and CSP. What happens when
> the parent page sets the location of a sandboxed iframe to a
> 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 + "#" + fragment -> bytes -> decode as
utf-8 -> script source algorithm for HTML to reference.
define more than that and even that it does a crappy job at currently.
More information about the whatwg