[Webkit-unassigned] [Bug 36481] Web Inspector: Edit Tag Names

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36481





--- Comment #10 from Pavel Feldman <pfeldman at chromium.org>  2010-03-27 00:06:53 PST ---
(In reply to comment #8)
> Created an attachment (id=51811)
 --> (https://bugs.webkit.org/attachment.cgi?id=51811) [details]
> [PATCH] "Edit Tag" and "Add Child Element"
> 
> This really just cleans up the code and adds a few ideas but has some serious
> UI issues that I have to work out. Some notes in no particular order:
> 
> - Blacklisted elements for "Edit Tag". I do not allow editing the tag name of
> html, head, title, or body in either the double click or context menu. I think
> doing so would likely be accidental.
> 

I would agree on html, head and body. Not so sure about title.

> - Update the closing tag. Unfortunately I do this onkeyup, which is noticeably
> slow. On key down does not yet have the content in a convenient form... I will
> likely need to switch this to onkeydown and do a String.fromCharCode(
> event.charCode ) and make it lowercase or not depending on if the shift key is
> down or not. I felt that was considerably ugly. The closing tag can be in any
> number of states (non-expanded, expanded, non-existent). I gracefully handle
> updating it all cases.
> 

Did you try textInput event? It should come when you need it and have an
appropriate data in place. Lowercase is no good for XML/XHTML where tag names
are case sensitive. Wrt closing tag states, can we refactor the code so that
you could handle it all at once? (Note that Alexander is currently working on
making close tag selectable, so one of you would need to merge).

> - There are serious UI jitters between committing the change, the front end
> getting the update, and the tree being repopulated. I have to work on making
> this a lot smoother. I know the setTimeout is unacceptable. I may instead add a
> function to a queue of actions to be performed when the updates arrive directly
> to the front-end instead of the hacky wait. I also need to prevent an expanded
> node collapsing the tree before the new update comes in and expands again.
> 
> Any ideas on the UI problems would be much appreciated.

It is not that setTimeout is unacceptable, it will simply not work in Chromium
since front-end is truly asynchronous. The reason you have delay is that we do
coalescing dom update upon events in the front-end (see updateModifiedNodesSoon
vs updateModifiedNodes). You should call updateModifiedNodes from within
didChangeTagName to have instant update (look at how Edit as HTML is
implemented).

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