Bug 30522

Summary: Web Inspector: DOM exceptions should be more human readable
Product: WebKit Reporter: Brian Weinstein <bweinstein>
Component: Web InspectorAssignee: Nobody <webkit-unassigned>
Status: ASSIGNED    
Severity: Normal CC: aroben, darin, eric, ggaren, graouts, inspector-bugzilla-changes, keishi, pfeldman, rik, robert.colburn+bugzilla, sam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 116924    
Attachments:
Description Flags
Log the description when a DOM Exception is logged
eric: review-, bweinstein: commit-queue-
Patch w/ Better Test - Addresses Eric's Comments
bweinstein: commit-queue-
Change from description to explanation sam: review-, bweinstein: commit-queue-

Brian Weinstein
Reported 2009-10-19 10:46:49 PDT
Bug 6745 covered human readable DOM exceptions in the Inspector/JavaScript Console on exceptions that were thrown during the execution of JavaScript on the page. This is the main place exceptions will be thrown, but it misses two cases that are also useful. 1) If a developer calls console.log() on a DOM exception: try { document.appendChild(); } catch (e) { console.log(e); } 2) if a developer writes code in the interactive console that invokes a DOM exception: > document.appendChild() Both of these cases would benefit from human readable DOM Exceptions, and this bug is to track both of these.
Attachments
Log the description when a DOM Exception is logged (11.78 KB, patch)
2009-10-19 14:20 PDT, Brian Weinstein 		eric: review-
bweinstein: commit-queue-
DetailsFormatted DiffDiff
Patch w/ Better Test - Addresses Eric's Comments (7.53 KB, patch)
2009-10-21 13:49 PDT, Brian Weinstein 		bweinstein: commit-queue-
DetailsFormatted DiffDiff
Change from description to explanation (18.34 KB, patch)
2009-10-21 17:23 PDT, Brian Weinstein 		sam: review-
bweinstein: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Brian Weinstein
Comment 1 2009-10-19 14:20:09 PDT
Created attachment 41451 [details] Log the description when a DOM Exception is logged
Eric Seidel (no email)
Comment 2 2009-10-21 10:43:42 PDT
Comment on attachment 41451 [details] Log the description when a DOM Exception is logged Seems that this test would be clearer w/o using console.log. Do you really want to log all of the constants on the exception, or are you just trying to log the description? A script-test may be a better choice for this style of test, since there you could use "debug()" easily for printing like this. Ideally a test should carry test expectations in it instead of just dumping data, however that may not be possible/appropriate for this particular test. Sad that Exceptions don't have any sort of base class. Is "description" covered by any ECMA spec? r- since the test is so hard to read with all the extra console.log linenumber output.
Eric Seidel (no email)
Comment 3 2009-10-21 10:44:37 PDT
http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree has information on how to write script-tests if you're interested.
Brian Weinstein
Comment 4 2009-10-21 12:02:52 PDT
(In reply to comment #2) > (From update of attachment 41451 [details]) > Seems that this test would be clearer w/o using console.log. What do you recommend instead? Ah, I see below you recommend debug(), I'll try that. > Do you really want to log all of the constants on the exception, or are you > just trying to log the description? All I'm interested in was the description, but I thought the other things could be useful, I'll just log the description. > A script-test may be a better choice for this style of test, since there you > could use "debug()" easily for printing like this. I'll look at that and upload a new patch. > Ideally a test should carry test expectations in it instead of just dumping > data, however that may not be possible/appropriate for this particular test. That can be done if I just want to log exceptions. > Sad that Exceptions don't have any sort of base class. > > Is "description" covered by any ECMA spec? > No, this is a developer feature so the developer can get a readable description of the exception fired through the Inspector. > r- since the test is so hard to read with all the extra console.log linenumber > output. Understood, I'll make it a cleaner test. Thanks!
Brian Weinstein
Comment 5 2009-10-21 13:49:32 PDT
Created attachment 41609 [details] Patch w/ Better Test - Addresses Eric's Comments
Eric Seidel (no email)
Comment 6 2009-10-21 14:36:54 PDT
Comment on attachment 41609 [details] Patch w/ Better Test - Addresses Eric's Comments You could use: shouldBeEqualToString("e.name", "NOT_FOUND_ERR") to make parts of the test self-documenting. Obviously the description stuff might vary more between browsers and you may want to leave as just "debug()" The change looks OK as is, but using shouldBe or shouldBeEqualToString would be nicer.
Brian Weinstein
Comment 7 2009-10-21 17:22:32 PDT
Committed original patch in r49222, rolled out in r49224 because description can't be exported because it conflicts with NSObject. About to upload a patch that renames to explanation.
Brian Weinstein
Comment 8 2009-10-21 17:23:15 PDT
Created attachment 41624 [details] Change from description to explanation
Sam Weinig
Comment 9 2009-10-21 19:00:45 PDT
Comment on attachment 41624 [details] Change from description to explanation I don't think we should make this change since I don't think adding unnecessary JS API is a good idea. Instead, we should just route the DOM exception information up to the inspector and do the special behavior there.
Adam Barth
Comment 10 2009-11-12 18:41:32 PST
Comment on attachment 41609 [details] Patch w/ Better Test - Addresses Eric's Comments Cleaning up pending-commit.
Rob Colburn
Comment 11 2012-06-11 10:06:24 PDT
Old bug. What's the status here?
Radar WebKit Bug Importer
Comment 12 2014-12-17 11:21:55 PST
<rdar://problem/19281490>
Radar WebKit Bug Importer
Comment 13 2014-12-17 11:25:58 PST
<rdar://problem/19281620>
Note You need to log in before you can comment on or make changes to this bug.