[Webkit-unassigned] [Bug 147438] New: Web Inspector: hard to find callers that cause ES6 TypeErrors thrown during inspector initialization

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 29 22:18:18 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=147438

            Bug ID: 147438
           Summary: Web Inspector: hard to find callers that cause ES6
                    TypeErrors thrown during inspector initialization
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Inspector
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: burg at cs.washington.edu
                CC: ggaren at apple.com, graouts at webkit.org,
                    joepeck at webkit.org, jonowells at me.com,
                    mattbaker at apple.com, nvasilyev at apple.com,
                    saambarati1 at gmail.com, timothy at apple.com,
                    utatane.tea at gmail.com,
                    webkit-bug-importer at group.apple.com
            Blocks: 147066

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150730/df16911e/attachment.html>


More information about the webkit-unassigned mailing list