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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 12 Nov 2012 01:55:36 -0800
Message-ID: <50A0C798.30005@mit.edu>
To: whatwg <whatwg@lists.whatwg.org>
Cc: Olli Pettay <opettay@mozilla.com>
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
Received on Monday, 12 November 2012 12:21:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT