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

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Mon, 12 Nov 2012 20:45:05 +0200
Message-ID: <50A143B1.9050403@helsinki.fi>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: whatwg <whatwg@lists.whatwg.org>
On 11/12/2012 11:55 AM, 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...

First I thought the spec behavior would make more sense, but if the error is about executing something bound to
window A it would be quite surprising to get error event on window B.
But I don't feel strongly about this.


> -Boris
Received on Monday, 12 November 2012 20:14:58 UTC

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