[Webkit-unassigned] [Bug 32568] Web Inspector: Context Menus should be used in more places

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 5 01:07:48 PST 2010


--- Comment #15 from Pavel Feldman <pfeldman at chromium.org>  2010-01-05 01:07:47 PST ---
(From update of attachment 45865)
Are you saying there is no way to remove breakpoint without involving context
menu now? I'd be strongly against that. I think this strategy of breakpoint
management is cluttering UI when investigating the code (and hence put many

On a more general note, I think that using Xcode as an IDE of reference is
wrong. I know that you guys are used to it, but that's not the case for the web
developers out there. I personally find Xcode confusing. I'd stick to more
standard (wide-spread) platform such as Eclipse instead. We know that Java was
getting the most IDE love for the past 10 years and hence got most advanced and

The Eclipse's model for breakpoint management (and I like it) is following:
1) Click in gutter sets / removes the breakpoint
2) Context menu in gutter has following actions:
  "Toggle Breakpoint" (sets/removes);
  "Disable Breakpoint" / "Enable Breakpoint" based on its enabled state
  "Breakpoint Properties..." invokes a modal dialog that allows setting enabled
state, hit count, enable condition, other java-specific options.
So I think that removing breakpoint should be easier than disabling it. Hence I
think that enable/disable breakpoint belongs only to context menu and
breakpoint manager. Worst case, lets leave it as is with three click states.

Actually, there is one important scenario where I need to enable / disable
breakpoints fast. That's when I need to debug n-th iteration of something. I
run program and hit them all, disable then one by one, then count to the
iteration I am interested it and then restore them all. But that's all due to
the lack of 'Disable Breakpoints' action in the debugger and / or breakpoint
manager. I think we need to implement it asap.

One more thing to note: in IDE, breakpoints 'follow' code when you insert lines
while editing. In our environment editing is disconnected and on the subsequent
run of the app, breakpoints are all wrong. So removing them easily is

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list