1.13 KB, application/zip
I noticed a problem in Firefox ESR 45. It also happens in Nightly 55. When inspecting element in browser UI, sometimes the element isn't selected in markup. Here's how to reproduce the bug: 1. Create pref dom.allow_XUL_XBL_for_file as true. Set pref devtools.inspector.showAllAnonymousContent to true. 2. Open attached .html page. 3. Press Ctrl+Shift+C and inspect text "123" on the page. Result: There's no specific element selected in markup Expected: <pre> element should be visible and selected in markup The bug has two implications: 1) If I simply clicked on the page to get a neighboring element, to scroll it into view in markup, it fails. 2) If I actually want to inspect the element, then I have to reopen inspector.
DevTools bug triage (filter on CLIMBING SHOES).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Error stack: console.error: Message: TypeError: nodes is undefined Stack: children@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/inspector.js:1423:1 handler@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/protocol.js:1082:19 onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1760:15 receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:761:7
Weird, after doing some testing I don't see the error anymore. But I can definitely reproduce the problem
Ah, so it works properly if you expand the <test> element from the inspector, and it breaks if it is expanded via the highlighter (starting with ctrl+shift+c)
Once it gets messed up via 'select element' it can't get in a good state again unless if the toolbox is closed and reopened, as stated in Comment 0
As discussed with bgrins the other day, bumping this to P2.
Priority: P3 → P2
Summary: Anonymous/XUL inspection: (bindings) Ctrl+Shift+C sometimes doesn't select existing element in inspector → Anonymous/XUL/XBL inspection: (bindings) Ctrl+Shift+C sometimes doesn't select existing element in inspector
Did some debugging on this. As best as I can tell, if you manually expand the markup view to the XBL anon content it works fine. When it breaks is when you 'pick the element' with the highlighter. Not only does it not pick the node, but it makes it so you can't expand the <test> node (unless if it was expanded previously). This is because we hit a case where the parent is unknown, so a standin is created (https://dxr.mozilla.org/mozilla-central/source/devtools/shared/fronts/inspector.js?q=%27%22standin%22%27&redirect_type=single#559). The WalkerFront appears to keep that standin without it ever being written to, as the comment expects. I believe this is because the markup view never ends up requesting for children on the parent (which is not a problem with non XBL content that hits the same case, like the <foo> in: data:text/html,<div><foo><span>foo</span></foo></div>). Or at least, the 'write' call in protocol.js does fire for the NodeActor in HTML case and not for the XBL case. Also: if I set some padding on the parent to <children /> such that the parent gets picked before the child when highlighting things also work.
Given that we're getting rid of XBL this isn't high priority enough for me to look at.
And FWIW we are actively working to enable Shadow DOM inspection in Bug 1053898 (which will support both the normal toolbox and the browser toolbox)
I think this was fixed by Bug 1465873 as per local testing of Bugs 1360074 and Bug 1413808, along with https://bugzilla.mozilla.org/show_bug.cgi?id=1465873#c9.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.