[whatwg] Spec for handling runtime script errors doesn't seem to match reality
Simon Pieters
simonp at opera.com
Mon Nov 12 05:45:32 PST 2012
On Mon, 12 Nov 2012 10:55:36 +0100, Boris Zbarsky <bzbarsky at mit.edu> 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 7.1.3.5.1, 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
More information about the whatwg
mailing list