Bug 168761 - Web Inspector: Elements tab: show indicators for hidden DOM breakpoints
Summary: Web Inspector: Elements tab: show indicators for hidden DOM breakpoints
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Matt Baker
URL:
Keywords:
Depends on: 168101
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-22 19:43 PST by Matt Baker
Modified: 2017-04-03 15:09 PDT (History)
4 users (show)

See Also:


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 Details | Formatted Diff | Diff
[Video] w/ patch applied (1.34 MB, video/mp4)
2017-03-26 22:16 PDT, Matt Baker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Baker 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.
Comment 1 Devin Rousso 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?
Comment 2 Matt Baker 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.
Comment 3 Matt Baker 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.
Comment 4 Matt Baker 2017-03-26 22:15:07 PDT
Created attachment 305446 [details]
Patch
Comment 5 Matt Baker 2017-03-26 22:16:48 PDT
Created attachment 305447 [details]
[Video] w/ patch applied
Comment 6 Timothy Hatcher 2017-04-03 14:58:34 PDT
Comment on attachment 305446 [details]
Patch

This looks great! Nice job.
Comment 7 WebKit Commit Bot 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>
Comment 8 WebKit Commit Bot 2017-04-03 15:09:27 PDT
All reviewed patches have been landed.  Closing bug.