29251 2009-09-14 12:07:26 -0700 Implement distinguishing of un/conditional breakpoints in the Breakpoints sidebar pane 2026-01-12 09:08:44 -0800 1 1 1 Unclassified WebKit Web Inspector 528+ (Nightly build) All All NEW InRadar P2 Normal --- 1 apavlov webkit-unassigned bburg chrisjshull graouts inspector-bugzilla-changes mattbaker webkit-bug-importer oldest_to_newest 147131 0 apavlov 2009-09-14 12:07:26 -0700 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 967079 1 webkit-bug-importer 2014-01-12 16:13:54 -0800 <rdar://problem/15801499> 1051289 2 burg 2014-11-28 19:48:30 -0800 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? 1276289 3 bburg 2017-02-13 12:14:04 -0800 Maybe we can add a ? on top of the wedge. 1276334 4 mattbaker 2017-02-13 13:15:58 -0800 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. 1276337 5 mattbaker 2017-02-13 13:30:51 -0800 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.