684sigma Reporter
	Description • 7 years ago

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.

	Patrick Brosset <:pbro>
	Comment 1 • 7 years ago

DevTools bug triage (filter on CLIMBING SHOES).

	Brian Grinstead [:bgrins]
	Comment 2 • 7 years ago

Error stack:

console.error: 
  Message: TypeError: nodes[0] 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

	Brian Grinstead [:bgrins]
	Comment 3 • 7 years ago

Weird, after doing some testing I don't see the error anymore.  But I can definitely reproduce the problem

	Brian Grinstead [:bgrins]
	Comment 4 • 7 years ago

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)

	Brian Grinstead [:bgrins]
	Comment 5 • 7 years ago

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

	Patrick Brosset <:pbro>
	Comment 6 • 7 years ago

As discussed with bgrins the other day, bumping this to P2.

	Brian Grinstead [:bgrins]
	Comment 7 • 7 years ago

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.

	:Gijs (he/him)
	Comment 8 • 7 years ago

Given that we're getting rid of XBL this isn't high priority enough for me to look at.

	Brian Grinstead [:bgrins]
	Comment 9 • 7 years ago

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)

	Brian Grinstead [:bgrins]
	Comment 10 • 6 years ago

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.