|Summary:||Implement distinguishing of un/conditional breakpoints in the Breakpoints sidebar pane|
|Product:||WebKit||Reporter:||Alexander Pavlov (apavlov) <apavlov>|
|Component:||Web Inspector||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||bburg, chrisjshull, graouts, inspector-bugzilla-changes, mattbaker, webkit-bug-importer|
|Version:||528+ (Nightly build)|
Description Alexander Pavlov (apavlov) 2009-09-14 12:07:26 PDT
Currently there is no way to tell if a breakpoint in the sidebar has a condition associated with it. The original conditional breakpoints UI issue is https://bugs.webkit.org/show_bug.cgi?id=28908
Comment 2 Brian Burg 2014-11-28 19:48:30 PST
There is *sort of* a visual difference now when a breakpoint has any actions, but not for a conditional breakpoint. This would be an easy fix-Tim, any ideas for the icon?
Comment 3 Brian Burg 2017-02-13 12:14:04 PST
Maybe we can add a ? on top of the wedge.
Comment 4 Matt Baker 2017-02-13 13:15:58 PST
We don't style breakpoints with actions differently from default breakpoints, unless they are set to auto-continue (which breakpoints having actions typically are). What Other Do: - Chrome: conditional breakpoints are orange/yellow - Edge: overlays a "+" icon in the breakpoint - FireFox: look identical to regular breakpoints Fun Fact: Edge breakpoints are styled after Visual Studio, which also styles auto-continue breakpoints as a diamond rather than a circle.
Comment 5 Matt Baker 2017-02-13 13:30:51 PST
Three methods of distinguishing breakpoints come to mind: 1. Shape 2. Color 3. Decorations We only use method 2: unresolved breakpoints are gray, and disabled breakpoints are slightly transparent. There are accessibility concerns with method 2, but for non-critical UI hints color is a simple solution. Method 3 is interesting, and doesn't suffer from the same issues as method 2. However, since our breakpoints overlap the line number some accommodations would need to be made for large files.