1168689 - Browser inspector can't descend into <tabbrowser>

Status: RESOLVED FIXED

(DevTools :: Inspector, defect)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

When working on the responsive design mode, I've noticed some odd behavior.

1. Open Responsive Design
2. Open Browser Inspector
3. Enable inspector's pick mode
4. Hover on the responsive design preset menu

ER:

The <menulist> is selected in the inspector

AR:

The <tabbrowser> element, which the parent of all of the responsive design elements (as well as the actual <browser>), is selected.

After some testing, I noticed that "mousemove" events for the browser window also cannot descend into <tabbrowser>.  The |target| is always <tabbrowser> for any area within that element.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Gijs, do you know why <tabbrowser> would stop "mousemove" events from being able to see into the elements below it?  Where is the magic that causes this behavior?

Comment 2

[Patrick Brosset <:pbro>]

Thanks Ryan for spotting this.

When using the Browser Toolbox, the element picker listens to events on the whole browser UI, so that no matter if you move your mouse over the url bar or an element in the content page, the right element will be highlighted in the inspector.

It does this by attaching a few event handlers here: http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/highlighter.js#359

To do so, it needs a target that will emit events for all elements the mouse moves over.
The target it uses is returned by this helper function: http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/highlighter.js#3019

According to the function jsdoc, when we are using the Browser Toolbox (isRootActor==true), we end up using tabActor.window.

I think this points to: Services.wm.getMostRecentWindow("navigator:browser");
This is done in the ChromeActor (which is the actor that runs in the parent chrome process the browser toolbox connects to): http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/chrome.js#33

I just realized that with an e10s window, the same happens no matter if you're using the responsive view or not:
- open a new e10s window
- open any site, mozilla.org
- open the browser toolbox
- using the inspector element picker, try to hover over elements in the page

Comment 3

[:Gijs (out for now; he/him)]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> Gijs, do you know why <tabbrowser> would stop "mousemove" events from being
> able to see into the elements below it?  Where is the magic that causes this
> behavior?

I'm confused. comment #0 and comment #2 seem to be about quite different problems. If you follow the steps from comment #0 in beta, this is reproducible, but you can select content elements just fine (but not the responsive design controls). Not being able to select content elements is a problem in e10s mode. I don't know how to solve that, but it should probably be a different bug.

I expect that there is some issue with XBL here. A similar thing happens if you try to search for "#PanelUI-content" in the search box in the browser inspector. The inspector doesn't find anything, but if you type the final "s" after that string and hit enter, it does select the relevant element, which is embedded somewhere in a bunch of bindings for the main menu panel (ie the panel shown when you click the hamburger button).

Looking at the responsive design view code, it appends elements into the middle of an anonymous binding, without regard for <children> etc., and so the elements are anonymous as well.

In order to fix this, the picker would need to pick up anonymous children for chrome type docshells.

The mousemove event should have something like explicitOriginalTarget or whatever - I forget which exact property it is, but there are properties on there that tell you what anonymous XBL node inside the "real" node fired an event. This will also fix being able to e.g. inspect close buttons on tabs in the tabstrip.


Does this help?

Comment 4

[:Gijs (out for now; he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> In order to fix this, the picker would need to pick up anonymous children
> for chrome type docshells.

Where "this" is inspecting those elements, not making the elements non-anonymous (for which we'd need to mess with the bindings in question).

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=86160a8d7386

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: 0001-Bug-1168689-Allow-highlighter-to-see-XBL-anonymous-n.patch

This addresses the case in comment 0.  Like Gijs, I think the e10s case is something separate.

Comment 7

[Patrick Brosset <:pbro>]

(In reply to :Gijs Kruitbosch from comment #3)
> I'm confused. comment #0 and comment #2 seem to be about quite different
> problems. If you follow the steps from comment #0 in beta, this is
> reproducible, but you can select content elements just fine (but not the
> responsive design controls). Not being able to select content elements is a
> problem in e10s mode. I don't know how to solve that, but it should probably
> be a different bug.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6)
> Like Gijs, I think the e10s case is something separate.

Ah, my bad, sorry. You're right.

Looking at the patch J.Ryan submitted now.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/6a379cde49b6

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6a379cde49b6