Open
Bug 1399045
Opened 7 years ago
Updated 2 years ago
"Inspect Element" context menu not working on certain node if DevTools closed
Categories
(DevTools :: Inspector, defect, P2)
Tracking
(firefox57 fix-optional)
NEW
| Tracking | Status | |
|---|---|---|
| firefox57 | --- | fix-optional |
People
(Reporter: nachtigall, Unassigned)
References
Details
Attachments
(2 files)
STR:
===
1. Unzip attached example. This is from a live site, but I tried to minimize the code as much as I could.
2. Right-click > "Inspect Element" on the node.
ER:
===
The element node is selected.
AR:
===
The element is not selected. Instead the Inspector "picks" nothing.
I noticed that sometimes at least <body> is selected, and then it "stops" there. But mostly the Inspector just picks no element at all.
If the same is repeated while the DevTools are already open, then it works.
The page loads 2 JS files - if any if these JS files is not loaded, then it also works.
If you change the empty "class" or "tabindex" of the to-be-picked <p> element, then it also works.
FWIW, this also does not work in stable FF 55, so I do not think this is a regression but rather something that never really worked.
FWIW, it works in Chrome.
I guess it is a really rare edge case bug, but might happen in other scenarios as well.
Uh, forgot for the STR: The DevTools need to be closed. If they are open, then it works.
|
||
Comment 2•7 years ago
|
||
I'm investigating this a little bit. This seems to happen because of the focusin/focusout event handlers on the document. When the picked node gets focused in/out, a class a toggled on it, which causes a DOM mutation. It looks to me like this mutation prevents the inspector from picking that element when it first opens.
I'm trying to create a reduced test case, no luck so far, but I'll give it another shot.
|
|
||
Comment 3•7 years ago
|
||
I managed to find a reduced test case.
Here's what's needed to reproduce:
- on focusin, the node gets a new class
- on focusout, the class is removed
- the node has no other classes or ids
So what happens is:
- on right-click on the node, it gets focused, so it gets the new class
- in nsContextMenu.js, we create a unique selector for the node so that we can later find it again in the DOM once devtools is open:
http://searchfox.org/mozilla-central/rev/ed1d5223adcdc07e9a2589ee20f4e5ee91b4df10/browser/base/content/nsContextMenu.js#748-750
- then when the "inspect element" option is selected and devtools starts to open, the node gets blurred, and therefore the class is removed (focusout listener)
- when devtools is open and is ready to select the element, it runs a querySelector on the DOM with the selector previously saved:
http://searchfox.org/mozilla-central/rev/ed1d5223adcdc07e9a2589ee20f4e5ee91b4df10/devtools/client/framework/devtools.js#606-608
- this now fails because the class does not exist.
If the element had another class or an id, this would work, but unfortunately, the class that is added temporarily is the only thing we use to locate the node.
We should probably use something else.
This has been a difficult part to get right in the past too. We used to store the node itself. At some stage we decided to just store the selector, but as seen here this isn't perfect either in all cases.
Maybe we should set an attribute on this node at the platform level, and use this to find it later.
|
|
||
Updated•7 years ago
|
Priority: -- → P2
|
||
Comment 4•7 years ago
|
||
I am seeing this in any Slack workspace, too. Right-click on the text of a message, or the message input, for example, and try to Inspect Element. For me, it never works.
|
||
Updated•6 years ago
|
Product: Firefox → DevTools
|
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•