Bug 30735 - Web Inspector: hovering in the DOM tree it is very hard to double-click to edit
Summary: Web Inspector: hovering in the DOM tree it is very hard to double-click to edit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Timothy Hatcher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-23 20:13 PDT by Timothy Hatcher
Modified: 2009-10-24 20:01 PDT (History)
6 users (show)

See Also:


Attachments
Proposed Patch (2.60 KB, patch)
2009-10-24 10:08 PDT, Timothy Hatcher
pfeldman: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Hatcher 2009-10-23 20:13:43 PDT
When hovering in the DOM tree it is very hard to double-click to edit now. The other day I was editing the Inspector with the Inspector to quickly test things for the Timeline mock-up. And I was very frustrated when I went to double-click on an attribute or text node that it would shift under my and I might miss it.

I think we need to rethink the hover to add a new attribute changes. I feel this was better when it didn't shift so much, but since it changed to: ?="" it is more likely going to shift and rewrap.

Options I see are:

- Some control show up on hover that does not affect layout. THe control could have other things like "New Child", etc in there.
- Move the controls to the right end of the row, or the left before the node.

(There is also a bug when the hover causes the text to wrap to a new line. THer selection highlight does not grow, so you don't see the white text on the new line. updateSelection() needs called.)
Comment 1 Pavel Feldman 2009-10-23 22:13:13 PDT
(In reply to comment #0)
> When hovering in the DOM tree it is very hard to double-click to edit now. The
> other day I was editing the Inspector with the Inspector to quickly test things
> for the Timeline mock-up. And I was very frustrated when I went to double-click
> on an attribute or text node that it would shift under my and I might miss it.
> 
> I think we need to rethink the hover to add a new attribute changes. I feel
> this was better when it didn't shift so much, but since it changed to: ?="" it
> is more likely going to shift and rewrap.
> 

Actually, now that it has a timeout you have at least some chance of hitting what you want.

> Options I see are:
> 
> - Some control show up on hover that does not affect layout. THe control could
> have other things like "New Child", etc in there.
> - Move the controls to the right end of the row, or the left before the node.
> 
> (There is also a bug when the hover causes the text to wrap to a new line. THer
> selection highlight does not grow, so you don't see the white text on the new
> line. updateSelection() needs called.)

I don't think this operation should pop up on hover at all - it is not that important. I was thinking about a small "New" popup menu when user clicks "+" or "Insert" or win? Cmd+N would be too much I guess.
Comment 2 Timothy Hatcher 2009-10-23 23:20:58 PDT
I think the timeout makes it tricky. Since It is fine for a bit, then by the time I double-click it changes.

Not having it on hover would be fine too, if we find a discoverable way to do it.
Comment 3 Timothy Hatcher 2009-10-24 10:08:37 PDT
Created attachment 41783 [details]
Proposed Patch
Comment 4 Timothy Hatcher 2009-10-24 20:01:13 PDT
Committed r50032: <http://trac.webkit.org/changeset/50032>