958169 - Highlighter: When picking an element on the page, the Inspector tab should be opened if it isn't already

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Brian Grinstead [:bgrins]]

To reproduce:
* Open console tab
* Click the "Pick an element from the page" button from the commands in the top tab
* Click an element on the page

After clicking on this element, I'd like to be able to immediately see it selected in the inspector panel without having to switch to the panel.  This is, I believe, the most common desired behavior after selecting an element on the page, and consistent with other devtools behavior.

Comment 2

[Patrick Brosset <:pbro>]

So, this was done on purpose to allow other tools to select elements and do things with them.

It's easy to imagine that we'll want to create new tools that need element selection to work and provide information about that without wanting to switch to the inspector-panel.

One use case we do have today is the $0 token that one can use in the webconsole. It's, I think, pretty handy to be able to select the element and use $0 right away without ever having to leave the console. Also, the highlighter stays up for 1 sec, giving you time to confirm you've selected the right node.

Having said all this, I'm not sure about which way to go. If we only do have that 1 use case for now, I agree it may make more sense to switch to the inspector-panel.
We can always change this later if we do create tools that need node selections.

It would be great to gather feedback here before we take a decision.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

It's not just the web console, the debugger needs it too: bug 952277 and bug 918715 can now happen. There are also some GCLI commands that would benefit from this as well. Selecting a DOM node is such a common action in debugging web apps that I'm pretty sure we will find other uses as well.

Comment 4

[Joe Walker [:jwalker]]

Summary of arguments that I can see:

Against switching to the inspector:

* If other tools want to display the highlighted element in some way (e.g. maybe like a webconsole/$0 enhancement?) then they can't if the inspector grabs the toolbox (however we don't have other tool that do that yet)

For switching to the inspector:

* If you don't switch, then you can't see what you just did, so it feels broken
* It's what people expect from other tools (i.e. Safari+Chrome. There is no global highlight button in Dragonfly or IE11/F12)

Comment 5

[Joe Walker [:jwalker]]

(In reply to Panos Astithas [:past] from comment #3)
> It's not just the web console, the debugger needs it too: bug 952277 and bug
> 918715 can now happen. There are also some GCLI commands that would benefit
> from this as well. Selecting a DOM node is such a common action in debugging
> web apps that I'm pretty sure we will find other uses as well.

So to be clear this isn't about allowing other tools to display the highlighter, this is about whether pressing the highlight-by-mouse button switches to the inspector.

Comment 6

[Joe Walker [:jwalker]]

(In reply to Joe Walker [:jwalker] from comment #4)
> Summary of arguments that I can see:
> 
> Against switching to the inspector:
> 
> * If other tools want to display the highlighted element in some way (e.g.
> maybe like a webconsole/$0 enhancement?) then they can't if the inspector
> grabs the toolbox (however we don't have other tool that do that yet)

Comment 2 puts this much better than I did.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

> So to be clear this isn't about allowing other tools to display the
> highlighter, this is about whether pressing the highlight-by-mouse button
> switches to the inspector.

Thanks Joe, so for the debugger I don't think this matters at all. What the debugger needs, at least for the cases we have identified so far, is to translate a selection of a DOM node in the variables view or the Events pane to a highlighting action in the content, without clicking on the highlight button (by hovering or clicking the existing values).

It could matter if we had a flow where editing the value of a variable (say an existing DOM node reference) could let the user insert a reference to a different DOM node using the highlight button, but getting a JS reference to that node sounds hard (almost research work), so I don't think we should accommodate that.

Comment 8

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

(In reply to Patrick Brosset [:pbrosset] from comment #2)
> So, this was done on purpose to allow other tools to select elements and do
> things with them.
> 
> It's easy to imagine that we'll want to create new tools that need element
> selection to work and provide information about that without wanting to
> switch to the inspector-panel.

I agree that tools should, in general, be able to select elements without switch to the inspector tool.  But in this specific case (where an element is chosen after having clicked the "Pick an element..." button), I think it makes sense to switch to the Inspector panel after clicking.

> One use case we do have today is the $0 token that one can use in the
> webconsole. It's, I think, pretty handy to be able to select the element and
> use $0 right away without ever having to leave the console. Also, the
> highlighter stays up for 1 sec, giving you time to confirm you've selected
> the right node.

It's hard to know this for sure without exceptionally detailed telemetry, but my guess is that more web developers rely on mouse selection and visual inspection of the Inspector panel as their "main" inspection workflow than they use things like $0.  I view $0 as a bit more of an advanced tool, since it's not even obvious that it exists unless you know about.  But then, I am just guessing of course. :)

Another way to achieve what you're describing would be to enable the split console on with the Inspector panel open.  Then, even if picking an element switches to the Inspector tool, you can still use the split console to access $0 easily.

Comment 9

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Personally I don't see why the inspect element context menu item should behave any differently from the inspect button.

If a tool doesn't support element selection we should probably switch to the highlighter though.

Comment 10

[Patrick Brosset <:pbro>]

I'm going to prepare the patch for this. I think you guys are right.
If one day we get a tool that needs element selection, we'll think about it once again. For now it seems to make more sense to switch over to the inspector.

Comment 11

[Patrick Brosset <:pbro>]

The other question though is whether we should switch as soon as you click on the icon, or only once a node has been clicked on.

Comment 12

[Patrick Brosset <:pbro>]

Attachment: bug958169-switch-to-inspector-on-pick.patch

Ongoing try build: https://tbpl.mozilla.org/?tree=Try&rev=94224798bdb3

Very simple patch that switches to the inspector-panel before starting the pick process on the server side.

Comment 13

[Brian Grinstead [:bgrins]]

Comment on attachment 8359821 [details] [diff] [review]
bug958169-switch-to-inspector-on-pick.patch

Review of attachment 8359821 [details] [diff] [review]:
-----------------------------------------------------------------

I was expecting that it would wait to switch to inspector panel until after the element was selected from the page, but after playing with it a bit, it is nice to see the position of the hovered element in the markup tree while selecting.  r+ with a green try.

Comment 14

[Patrick Brosset <:pbro>]

Thanks Brian for the quick review.
Try is green apart from a couple of unrelated test failures.

I'll rebase/build/test and check this in.

Comment 15

[Patrick Brosset <:pbro>]

Fixed in fx-team: https://hg.mozilla.org/integration/fx-team/rev/aac03eb07632

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/aac03eb07632