This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13319 - Script errors should provide column position (add a fourth argument to onerror handler)
Summary: Script errors should provide column position (add a fourth argument to onerro...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/html5/webappapis...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-21 17:40 UTC by Adrian Bateman [MSFT]
Modified: 2013-07-25 23:43 UTC (History)
13 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2011-07-21 17:40:02 UTC
The window.onerror function needs a 4th parameter for column number. For sites that report exceptions to a server for post mortem analysis, column offsets enable developers to locate the source location in JavaScript files that have been minified or in other cases where many statements are on a single line. It would also be helpful if the spec called out that the line and column offsets should be 1 based so that implementations can be consistent. 

Proposed updates:
The function must be invoked with four arguments. The four arguments passed to the function are all DOMStrings; the first must give the message that the UA is considering reporting, the second must give the absolute URL of the resource in which the error occurred, the third must give the one based line number in that resource on which the error occurred and the fourth must give the one based column offset for the start of the statement which the error occurred.
Comment 1 Michael[tm] Smith 2011-08-04 05:34:17 UTC
mass-move component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-17 21:38:05 UTC
Does anyone implement this? What the spec says today is intended to match implementations. I don't mind augmenting it if implementations already do it or if we can show that it won't break anything.
Comment 3 Ian 'Hixie' Hickson 2011-09-23 22:38:26 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 2
Comment 4 Travis Leithead [MSFT] 2011-12-09 23:39:43 UTC
(In reply to comment #2)
> Does anyone implement this? What the spec says today is intended to match
> implementations. I don't mind augmenting it if implementations already do it or
> if we can show that it won't break anything.

I did some static analysis over our Bing web data. It was a fairly small sample size (1.2 M sites), but led me to some basic conclusions:

1. Most sites use a simple function to swallow any error notifications:
window.onerror = function() { return true; }
2. Some sites provide parameters to catch each of the three preexisting data points (though they're often not even used):
window.onerror = function(a,b,c) { return true; };
3. A few sites just expect an Error object (and don't use is)
window.onerror = function(e) { return true; }

I'm providing this info as informative--I don't think it's conclusive.

Given the data I've seen, I don't believe that the proposed change would break anything. However, it's given me enough confidence to move forward with a change to IE10. We'll try to ship it and see if there's any significant impact. If not, I'd like to push forward with this change.
Comment 5 Adrian Bateman [MSFT] 2011-12-13 17:13:20 UTC
Reopening for consideration - Travis provided the new info.
Comment 6 Ian 'Hixie' Hickson 2011-12-14 00:21:12 UTC
Sounds good.
Comment 7 Simon Pieters 2011-12-21 10:51:31 UTC
I don't object to adding this.

A few days ago I tried to study the compat impact by searching for window.onerror and arguments.length in google code search, but I didn't find anything that would be affected from the first few pages of results.
Comment 8 Ian 'Hixie' Hickson 2012-01-31 23:36:15 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: I've tried what you proposed. The fourth argument in the content handler attribute is called "column" for now; let me know if this causes any troubles.
Comment 9 contributor 2012-01-31 23:36:41 UTC
Checked in as WHATWG revision r6957.
Check-in comment: Try adding a fourth argument, 'column', to onerror handlers.
http://html5.org/tools/web-apps-tracker?from=6956&to=6957
Comment 10 Ian 'Hixie' Hickson 2013-07-25 23:43:33 UTC
Renamed in bug 22800 to match IE10.