New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 804610 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Last visit 28 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

[feature request] use setAttribute/getAttribute when modifying or showing element attributes in the inspector

Reported by trusktr@gmail.com, Jan 23 2018

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 10032.86.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.140 Safari/537.36

Steps to reproduce the problem:
1. Open https://examples.x3dom.org/example/x3dom_jQueryManip.xhtml
2. Inspect the elements, find the <Transform> element
3. In the inspector, try setting the attribute `translation` to `translation="0,5,0"` (observe nothing happens)
4. Then try using `$0.setAttribute('translation' '0,5,0')` in the console instead (observe that it works)

What is the expected behavior?
When modifying the attribute in the inspector's HTML view, it should work just like using $0.setAttribute does.

What went wrong?
It doesn't work.

Did this work before? N/A 

Chrome version: 63.0.3239.140  Channel: n/a
OS Version: 10032.86.0
Flash Version: 

This leads me to make a hypothesis that maybe Chrome isn't using `getAttribute` or `setAttribute` for showing and for allowing modification of the element attributes, respectively.

If this is the case, it'd be nice to use these APIs rather than accessing HTML engine internals, because nowadays it is possible for Custom Element authors to override {set,get}Attribute to do certain things, so bypassing these by reaching into the internals of the engine would cause certain things not to work right when people try modifying elements through the inspector.

Is this the case, that devtools sets/gets attributes in some other way? If so, in what way does it set and get attributes?
 

Comment 1 by woxxom@gmail.com, Jan 23 2018

Uhm, did you actually select the entire text of the attribute=value pair beofre pasting the new name=value pair? The <transform> element already has translation="0,0,0" attribute and when you double-click "translation" only the attribute name is selected so you need to either press Ctrl-A or use the mouse to select both the name and the value of the attribute.

Comment 2 by trusktr@gmail.com, Jan 23 2018

I've been using the element inspector for quite some time now, so I know how to change the values. :D

In the screenshot, you can see where my cursor is, and I've entered the value 5. When I press enter, the attribute appears to be changed, but I don't see the result in the rendering.

The second screenshot shows the value of Y translation is 5, but the box is still in the middle of the viewport.

When I use `setAttribute` in the console (the third screenshot) it works, notice the box moved to the top of the viewport.

Screenshot 2018-01-22 at 10.22.03 PM.png
43.3 KB View Download
Screenshot 2018-01-22 at 10.25.34 PM.png
361 KB View Download
Screenshot 2018-01-22 at 10.23.59 PM.png
136 KB View Download

Comment 3 by l...@chromium.org, Jan 23 2018

Labels: -Type-Bug Type-Feature
Owner: lushnikov@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report and use case.  Looking at the DevTools backend, our internal setAttribute() triggers code that checks for CustomElement state already:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Element.cpp?l=4080&gsn=WillModifyAttribute

lushnikov@, maybe this code has rotten?

Comment 4 by trusktr@gmail.com, Jan 23 2018

x3dom gives its elements a new `setAttribute` method, here: https://github.com/x3dom/x3dom/issues/816#issuecomment-359829001

Maybe that messes up devtools somehow?

Sign in to add a comment