Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality

On Mon, 12 Nov 2012 10:55:36 +0100, Boris Zbarsky <> wrote:

> Consider the attached testcase, which calls setTimeout on a window and
> passes in a function from a different window.
> When this function is then called, it throws.
> Gecko, WebKit, and Presto all seem to trigger the onerror handler of the
> window setTimeout was called on in this case.
> Per spec, section, we have:
>    Whenever an uncaught runtime script error occurs in one of the
>    scripts associated with a Document, the user agent must report
>    the error at the URL of the resource containing the script (as
>    established when the script was created), with the problematic
>    position (line number and column number) in that resource, in
>    the script's origin, using the onerror event handler of the
>    script's global object.
> But the global object is the window the function came from.  So the spec
> doesn't seem to match any of the above three rendering engines.  Does it
> match Trident?
> I ask because I'm worried about web compat here.  While I agree that
> what the spec says to do is the sensible thing (and in fact, I had
> accidentally switched Gecko to doing what the spec says here as part of
> working on something else entirely), if none of the UAs do it then there
> may be web content that relies on it not happening.  There are certainly
> tests in Mozilla's regression test suite that inadvertently rely on
> Gecko's current behavior...
> -Boris

I don't see any attachment. Maybe the whatwg list prunes them? Can you  
send it to www-archive?

Do browsers use the script's origin per spec, or do they use the  
function's global object's document's origin (for the purpose of tainting  
the arguments)?

Simon Pieters
Opera Software

Received on Monday, 12 November 2012 16:17:33 UTC