Bug 32568 – Web Inspector: Context Menus should be used in more places

• Component: Web Inspector (Deprecated)
• Status: RESOLVED INVALID

[Brian Weinstein]

RIght now the Context menu is only used in the Elements tree outline - there are more places it should be used:

- Datagrids
- Scripts Panel (for breakpoints)
- Resources Panel
- Timeline Panel
- Style Rules
- Maybe in the Console

There are plenty of places that it could and should be used for discoverability - we can learn from Firebug and where they use the context menu.

[Timothy Hatcher]

Console can have "Clear Scrollback". Not sure what else for Console.

Anywhere we have editing support should have "Edit". Like the Styles, Properties and Metrics panes. And in the Scripts panel Scope Variables pane.

[Brian Weinstein]

Created attachment 44893 [details]
[PATCH] Context Menu in DataGrid

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44893 [details] without any errors.

[Timothy Hatcher]

Comment on attachment 44893 [details]
[PATCH] Context Menu in DataGrid

We might want a different word for "Edit" when it is the creationNode. Maybe "Add New"?

[Brian Weinstein]

DataGrid context menu landed in r52165.

[Brian Weinstein]

Created attachment 44926 [details]
[PATCH] Context Menu in Console

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44926 [details] without any errors.

[Brian Weinstein]

Created attachment 44932 [details]
[PATCH] Context Menu in Console

Better ChangeLog + Addresses Joe's Comments.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44932 [details] without any errors.

[Timothy Hatcher]

Comment on attachment 44932 [details]
[PATCH] Context Menu in Console

THe name _contextMenuInConsole is redundant. _handleContextMenuEvent or _showContextMenu would be better.

[Brian Weinstein]

Console Context Menu landed in r52217.

[Brian Weinstein]

Created attachment 45865 [details]
[PATCH] Context Menus for Breakpoints

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45865 [details] without any errors.

[Timothy Hatcher]

Comment on attachment 45865 [details]
[PATCH] Context Menus for Breakpoints


> +        if (!sourceRow._breakpointObject && this.addBreakpointDelegate) {

Should you check for this.addBreakpointDelegate in the else condition too so it is balanced?

[Pavel Feldman]

Comment on attachment 45865 [details]
[PATCH] Context Menus for Breakpoints

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 breakpoints).

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 used.

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 important.

[Timothy Hatcher]

(In reply to comment #15)
> (From update of attachment 45865 [details])
> 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
> breakpoints).

What I told Brian on IRC was that we need a quick way to remove, and that method in Xcode is drag away and poof. So without that I think we would be more cumbersome in the removing category.

> 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
> used.

I would argue that most web developers don't use Eclipse. I know I never have, and my web developer friends never have. They don't use Xcode either. Perhaps the IDE most used is Visual Studio and it's JS debugger? I have no idea, but that seems more likely to be familiar than Eclipse.

I (and other Apple engineers) use Xcode as a reference for obvious reasons. None of us use Eclipse, so we have no familiarity with it. So I can't argue if it is better in practice, but I have no other reference IDE.

> 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.

Eclipse's way does sound logical and isn't too different from Xcode. Xcode has click to toggle enable/disabled because drag away does a remove. I don't think a "Toggle Breakpoint" item is needed, since it is more work to use than a single click.

I wish we never landed the three-click method, it is frustrating to use. We should mimic Eclipse, sicne we don't have drag and drop and drag to remove support yet.

> 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.

Maybe a double click on a breakpoint can toggle the enable state, and single click toggles remove?

> 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
> important.

We should have a context menu item in the gutter that says "Remove All Breakpoints".

[Brian Weinstein]

(In reply to comment #16)
> (In reply to comment #15)
> > (From update of attachment 45865 [details] [details])
> > 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
> > breakpoints).
> 
> What I told Brian on IRC was that we need a quick way to remove, and that
> method in Xcode is drag away and poof. So without that I think we would be more
> cumbersome in the removing category.
> 
> > 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
> > used.
> 
> I would argue that most web developers don't use Eclipse. I know I never have,
> and my web developer friends never have. They don't use Xcode either. Perhaps
> the IDE most used is Visual Studio and it's JS debugger? I have no idea, but
> that seems more likely to be familiar than Eclipse.
> 

Visual Studio uses click to add/click to remove, with enable/disable, and a list of properties to edit being context menu entries (location, condition, hit count, etc).

My new idea for what we should have:

Click in the gutter adds/removes a breakpoint:

Context Menu on Breakpoint: Edit Breakpoint, Disable Breakpoint, Remove Breakpoint
Context Menu on No Breakpoint: Add Breakpoint, Add Conditional Breakpoint.

What do you think about that?

[Brian Weinstein]

 > My new idea for what we should have:
> 
> Click in the gutter adds/removes a breakpoint:
> 
> Context Menu on Breakpoint: Edit Breakpoint, Disable Breakpoint, Remove
> Breakpoint
> Context Menu on No Breakpoint: Add Breakpoint, Add Conditional Breakpoint.
> 
> What do you think about that?

Oh, and remove all breakpoints should be there no matter what, below the divider.

[Timothy Hatcher]

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (From update of attachment 45865 [details] [details] [details])
> > > 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
> > > breakpoints).
> > 
> > What I told Brian on IRC was that we need a quick way to remove, and that
> > method in Xcode is drag away and poof. So without that I think we would be more
> > cumbersome in the removing category.
> > 
> > > 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
> > > used.
> > 
> > I would argue that most web developers don't use Eclipse. I know I never have,
> > and my web developer friends never have. They don't use Xcode either. Perhaps
> > the IDE most used is Visual Studio and it's JS debugger? I have no idea, but
> > that seems more likely to be familiar than Eclipse.
> > 
> 
> Visual Studio uses click to add/click to remove, with enable/disable, and a
> list of properties to edit being context menu entries (location, condition, hit
> count, etc).
> 
> My new idea for what we should have:
> 
> Click in the gutter adds/removes a breakpoint:
> 
> Context Menu on Breakpoint: Edit Breakpoint, Disable Breakpoint, Remove
> Breakpoint
> Context Menu on No Breakpoint: Add Breakpoint, Add Conditional Breakpoint.
> 
> What do you think about that?

That sounds fine to me.

Edit Breakpoint and Add Conditional Breakpoint should have … at the end to show there is further action needed.

[Patrick Mueller]

(In reply to comment #16)

> I would argue that most web developers don't use Eclipse. I know I never have,
> and my web developer friends never have. They don't use Xcode either. Perhaps
> the IDE most used is Visual Studio and it's JS debugger? I have no idea, but
> that seems more likely to be familiar than Eclipse.
> 
> I (and other Apple engineers) use Xcode as a reference for obvious reasons.
> None of us use Eclipse, so we have no familiarity with it. So I can't argue if
> it is better in practice, but I have no other reference IDE.

It seems likely to me that most web developers are not familiar with Eclipse, however, they're likely not familiar with XCode either.  I have long-standing ties to Eclipse, but for me, it has the best debug interface I've ever used.  For Java anyway, unsure about other language's debug support in Eclipse.  Unfortunately, there's a bit of a hurdle getting up to speed with Eclipse the first time, and if you want to see the best of Eclipse, you should use the Java-based tooling, and so if you don't want to play with some Java ...

Here's some reading/watching developer resources on Eclipse Java debugging:

- http://eclipsetutorial.sourceforge.net/debugger.html - 7  15 minute lessons on the debugger
- http://www.vogella.de/articles/EclipseDebugging/article.html - web page with a bunch of pictures
- http://bit.ly/6nT8Qr - current Eclipse help reference

> I wish we never landed the three-click method, it is frustrating to use. We
> should mimic Eclipse, sicne we don't have drag and drop and drag to remove
> support yet.

That would be my fault.  I desperately wanted toggle on/off support, didn't care about the enable/disable, but left it in as the third toggle as I figured someone must like it.  Let's get rid of the tri-state and just make the click toggle on/off.  Easy to fix.

BTW, the "drag away and poof breakpoint to remove" sounds like too much precise work for the user to me.  Compared to a single click.  But I've not significantly used XCode.

Of course, we could have "Eclipse bindings" and "XCode bindings" or something.  Eclipse has some level of emacs and vi keyboard support, IIRC :-)

> Maybe a double click on a breakpoint can toggle the enable state, and single
> click toggles remove?

Sounds confusing.

[Pavel Feldman]

Sounds like we are all in agreement. (I filed separate bug on 'deactivate': https://bugs.webkit.org/show_bug.cgi?id=33217).

[Brian Weinstein]

Comment on attachment 45865 [details]
[PATCH] Context Menus for Breakpoints

A variation on this was landed in r52820.

[Brian Burg]

This discussion is mostly outdated. Please file new bugs against inspector with new context menu suggestions.