Bug 147438 - Web Inspector: hard to find callers that cause ES6 TypeErrors thrown during inspector initialization
Summary: Web Inspector: hard to find callers that cause ES6 TypeErrors thrown during i...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks: InspectorDebug
  Show dependency treegraph
 
Reported: 2015-07-29 22:18 PDT by Brian Burg
Modified: 2016-12-13 15:34 PST (History)
6 users (show)

See Also:


Attachments
reduced test case (516 bytes, text/html)
2015-09-08 09:41 PDT, Brian Burg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Burg 2015-07-29 22:18:18 PDT
I have run into the following situation: a code refactoring I made introduced a TypeError, thrown by a caller that erroneously invokes an ES6 class constructor during inspector initialization. Unfortunately, the only error shown (with logging to console by stderr) is:

file:///Users/burg/repos/webkit-dev/WebKitBuild/Release/WebInspectorUI.framework/Resources/Views/DataGrid.js:28:16: CONSOLE ERROR TypeError: Cannot call a class constructor


Currently, ConsoleClient only captures a call stack for console messages with the "trace" type. So, the console only displays the first frame from the uncaught exception. The check that throws a TypeError is directly emitted into the constructor bytecode stream, which is what's seen here. But it's really the caller (next call frame) that we care about. So this seems to mostly be a problem associated with new ES6 errors with mysterious source locations.

I propose two possible fixes, which are not mutually exclusive:

* omit the call frame that's currently reported, since it is misleading to a user who is trying to debug the invalid call.
* always capture/log multiple stack frames for uncaught exceptions, just like ConsoleClient does for "trace" messages.

I welcome your thoughts on this issue prior to writing code.
Comment 1 Radar WebKit Bug Importer 2015-07-29 22:18:33 PDT
<rdar://problem/22066390>
Comment 2 Joseph Pecoraro 2015-07-30 11:22:34 PDT
What I would probably do is remote debug the failed inspector with a known good inspector and then reload the failed inspector page.
Comment 3 Brian Burg 2015-09-08 09:41:09 PDT
Created attachment 260764 [details]
reduced test case