Bug 147973 - Web Inspector: Flash DOM node attribute on change
Summary: Web Inspector: Flash DOM node attribute on change
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-08-13 00:07 PDT by Devin Rousso
Modified: 2015-08-13 19:20 PDT (History)
8 users (show)

See Also:


Attachments
Patch (10.46 KB, patch)
2015-08-13 00:16 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (10.95 KB, patch)
2015-08-13 14:23 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (10.94 KB, patch)
2015-08-13 16:50 PDT, Devin Rousso
timothy: review+
Details | Formatted Diff | Diff
Patch (10.71 KB, patch)
2015-08-13 18:26 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Devin Rousso 2015-08-13 00:07:19 PDT
When an attribute of a DOM node changes, flash the value (if it doesn't exist, flash the name of the attribute) to indicate that it has changed.
Comment 1 Devin Rousso 2015-08-13 00:16:59 PDT
Created attachment 258882 [details]
Patch
Comment 2 Timothy Hatcher 2015-08-13 03:58:14 PDT
Comment on attachment 258882 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=258882&action=review

> Source/WebInspectorUI/UserInterface/Views/DOMTreeUpdater.js:120
> +                    nodeItem.nodeGenerallyChanged = nodeGenerallyChanged;

Why not just pass this as an argument to updateTitle? updateTitle can pass it around internally. It seems odd to hang this temp data off the node tree element.
Comment 3 BJ Burg 2015-08-13 08:13:05 PDT
Comment on attachment 258882 [details]
Patch

'Generally' is a filler word here, and should be removed or replaced. Can you rename nodeGenerallyChanged to nodeStateChanged?
Comment 4 Devin Rousso 2015-08-13 11:55:37 PDT
(In reply to comment #2)
> Comment on attachment 258882 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=258882&action=review
> 
> > Source/WebInspectorUI/UserInterface/Views/DOMTreeUpdater.js:120
> > +                    nodeItem.nodeGenerallyChanged = nodeGenerallyChanged;
> 
> Why not just pass this as an argument to updateTitle? updateTitle can pass
> it around internally. It seems odd to hang this temp data off the node tree
> element.

I wanted to use a temp item to allow for innerHTML change flashing to work too.  I tried this before and passing it through the title didn't work and added parameters to a lot of functions.  I feel that doing it this way doesn't add more clutter in the parameter passing down the chain.
Comment 5 Devin Rousso 2015-08-13 14:23:26 PDT
Created attachment 258935 [details]
Patch
Comment 6 Radar WebKit Bug Importer 2015-08-13 14:23:48 PDT
<rdar://problem/22275991>
Comment 7 Joseph Pecoraro 2015-08-13 14:51:00 PDT
Comment on attachment 258935 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=258935&action=review

> Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:199
> +    set nodeStateChanged(change)
> +    {
> +        this._nodeStateChanged = change;
> +    }

Could there be multiple attribute changes to a node in one batch of updates? If so, does this only cover one of the updates and not all of them?

> Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:1098
> +                let attrValueElement = document.createElement("a");

This scares me. We are shadowing attrValueElement with `let`. Why not just use a new local `linkElement`?

> Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:1471
> +        if (element.classList.contains("node-state-changed"))
> +            element.classList.remove("node-state-changed");

Seems we could just call remove, if it is not there nothing happens.

> Source/WebInspectorUI/UserInterface/Views/DOMTreeUpdater.js:122
> +                nodeItem.updateTitle();
>              }

Previously there would have been a `continue` here. Now there isn't. Is that okay?
Comment 8 Devin Rousso 2015-08-13 16:26:32 PDT
Comment on attachment 258935 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=258935&action=review

>> Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:1098
>> +                let attrValueElement = document.createElement("a");
> 
> This scares me. We are shadowing attrValueElement with `let`. Why not just use a new local `linkElement`?

That was an accident.  It was only supposed to be attrValueElement and not have a let in front of it.  I used the same variable because then if the link changes for an attribute, it will still flash.

>> Source/WebInspectorUI/UserInterface/Views/DOMTreeUpdater.js:122
>>              }
> 
> Previously there would have been a `continue` here. Now there isn't. Is that okay?

I restructured this so that the continue is in the check above:  if (!nodeItem)
Comment 9 Devin Rousso 2015-08-13 16:50:28 PDT
Created attachment 258956 [details]
Patch
Comment 10 Timothy Hatcher 2015-08-13 18:13:08 PDT
Comment on attachment 258956 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=258956&action=review

> Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:1466
> +            this.classList.remove("node-state-changed");

Does this handle rapid updates well? We have had issues with removing class name mid animation causing it to stop abruptly. Ideally the animation here would restart and darken back up and start to animate back to transparent.

> Source/WebInspectorUI/UserInterface/Views/DOMTreeUpdater.js:114
> +                let nodeItem = this._treeOutline.findTreeElement(node);

nodeTreeElement
Comment 11 Devin Rousso 2015-08-13 18:24:57 PDT
(In reply to comment #10)
> > Source/WebInspectorUI/UserInterface/Views/DOMTreeElement.js:1466
> > +            this.classList.remove("node-state-changed");
> 
> Does this handle rapid updates well? We have had issues with removing class
> name mid animation causing it to stop abruptly. Ideally the animation here
> would restart and darken back up and start to animate back to transparent.

Yes, this handles reselecting and restarts the animation in that case.
Comment 12 Devin Rousso 2015-08-13 18:26:22 PDT
Created attachment 258966 [details]
Patch
Comment 13 WebKit Commit Bot 2015-08-13 19:20:25 PDT
Comment on attachment 258966 [details]
Patch

Clearing flags on attachment: 258966

Committed r188429: <http://trac.webkit.org/changeset/188429>
Comment 14 WebKit Commit Bot 2015-08-13 19:20:29 PDT
All reviewed patches have been landed.  Closing bug.