Bug 168761

Summary: Web Inspector: Elements tab: show indicators for hidden DOM breakpoints
Product: WebKit Reporter: Matt Baker <mattbaker>
Component: Web InspectorAssignee: Matt Baker <mattbaker>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, hi, inspector-bugzilla-changes, timothy
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Bug Depends on: 168101    
Bug Blocks:    
Attachments:
Description Flags
[Image] DOM breakpoint gutter enhancements
none
Patch
none
[Video] w/ patch applied none

Matt Baker
Reported 2017-02-22 19:43:01 PST
Created attachment 302484 [details] [Image] DOM breakpoint gutter enhancements Summary: Show indicators for hidden DOM breakpoints. Proposal: Show a hollow breakpoint indicator on collapsed DOM tree elements, when one or more child elements has a breakpoint. See attached mockup.
Attachments
[Image] DOM breakpoint gutter enhancements (145.91 KB, image/png)
2017-02-22 19:43 PST, Matt Baker 		no flags
Details
Patch (14.72 KB, patch)
2017-03-26 22:15 PDT, Matt Baker 		no flags
DetailsFormatted DiffDiff
[Video] w/ patch applied (1.34 MB, video/mp4)
2017-03-26 22:16 PDT, Matt Baker 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Devin Rousso
Comment 1 2017-02-23 10:00:47 PST
Looks awesome! Few comments: - Are these indicators going to be clickable, similar to breakpoints in the gutter in the Resources tab? - We currently have an indicator for CSS pseudo-classes, so how would that interplay with that? - Lastly, what do you want to do in the case that the user wants to put a breakpoint on the <html> tag?
Matt Baker
Comment 2 2017-02-23 13:56:33 PST
(In reply to comment #1) > Looks awesome! Few comments: > - Are these indicators going to be clickable, similar to breakpoints in the > gutter in the Resources tab? DOM breakpoint indicators have content menu support only for now (https://webkit.org/b/168101). In the future it could be useful to support single-clicking to toggle the disabled state. > - We currently have an indicator for CSS pseudo-classes, so how would that > interplay with that? There shouldn't be any conflict, for the reason below. Will confirm this. > - Lastly, what do you want to do in the case that the user wants to put a > breakpoint on the <html> tag? The attached mockup is a little misleading. In practice, the DOM tree content view makes room for the gutter when the first breakpoint is added. There is no overlap with disclosure triangles.
Matt Baker
Comment 3 2017-03-26 21:50:58 PDT
It probably makes sense to disallow editing of subtree breakpoints from the "hollow" breakpoint marker's context menu. A "Reveal Breakpoint" command that revealed the first descendant with a DOM breakpoint would be nice though.
Matt Baker
Comment 4 2017-03-26 22:15:07 PDT
Created attachment 305446 [details] Patch
Matt Baker
Comment 5 2017-03-26 22:16:48 PDT
Created attachment 305447 [details] [Video] w/ patch applied
Timothy Hatcher
Comment 6 2017-04-03 14:58:34 PDT
Comment on attachment 305446 [details] Patch This looks great! Nice job.
WebKit Commit Bot
Comment 7 2017-04-03 15:09:26 PDT
Comment on attachment 305446 [details] Patch Clearing flags on attachment: 305446 Committed r214844: <http://trac.webkit.org/changeset/214844>
WebKit Commit Bot
Comment 8 2017-04-03 15:09:27 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.