1434441 - The element picker is only enabled for the Inspector

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Hubert B Manilla]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

- Open any webpage
- Open the devtools 
- Select the inspector panel
- Click on the element picker
- move the mouse pointer over the page
-  select another panel (maybe console)


Actual results:

The element picker gets switched off, if clicked again, it auto switches back to the inspector panel

http://g.recordit.co/esVIBi2irv.gif


Expected results:

The element picker should stay switched on, so it can be used across panels.
Chrome allows that as well

http://g.recordit.co/Kx5hKusgfp.gif

Comment 1

[Hubert B Manilla]

Clicking the image links does not seem to work. Selecting them an pasting the browser seems to work better.

Comment 2

[Patrick Brosset <:pbro>]

Thanks for filing Hubert.
This was actually a *feature* we added 4 years ago in bug 961771.
At the time, this wasn't discussed much though, it just made sense to me that it would behave this way. So I'm willing to be convinced that it's not a good idea.
Having said that, what do you expect to happen once you select an element in the page? Right now, Chrome does allow the picker to continue existing even if you switch to another panel while it's ON, but then as soon as you select an element, it switches back to the inspector.
It makes me wonder what is the use of being able to switch to another panel while picking?

@Victoria: this impacts the user experience, so pinging you here in case you have a strong opinion on this.

Comment 3

[Victoria Wang [:victoria]]

At the moment, I guess I don't see a reason for the picker to work in other panels - does the Chrome functionality feel better? I think for me it would just feel like weird Inspector residue to have the picker left on. 

This could be useful in the future when we have a more powerful picker tool (could visually persist in the page, provide entry points into layout tools, and possibly work with the Console/Debugger somehow - visually selecting event listeners?).

Comment 4

[Hubert B Manilla]

@Victoria @Pbro

Thanks for the response. I agree it feels weird to leave the picker on.

- One point is the fact that the element picker is positioned in place that gives the impression that it can be used across any of the panels (if it was only meant for the inspector it should probably sit within the inspector)

- Yeah Chrome's still switches  back to the inspector, but being able to switch to another panel and still have the element picker enabled, means i can for example can switch to the z-index devtool extension panel, turn on the element picker, select the desired element(even if it auto switches back to the inspector) and use $0 to get the selected element, as to having to implement a completely new element picker functionality particularly for the z-index devtool extension.

Possible Solutions

- Maybe move the element picker into the inspector, since its only used by the inspector.
- Do what chrome does.
- Disable the element picker when an element is selected, and select the element node in the inspector but do not auto switch back to the inspector(better option).

These are just my thoughts, there might be better opinions.

Comment 5

[Hubert B Manilla]

i think my main point would be having to implement an element picker functionality in a devtool extension when the native one can be used.

Comment 6

[Hubert B Manilla]

tots?

Comment 7

[Patrick Brosset <:pbro>]

(In reply to Hubert B Manilla from comment #5)
> i think my main point would be having to implement an element picker
> functionality in a devtool extension when the native one can be used.
That's a very good point. Extensions that (in some way) select elements in the page should have the ability to rely on a similar UX than that of the element picker. Now, we did precisely this for the new accessibility tools (which I think shipped with Firefox 61, and need to be enabled from the settings panel first). When you switch to that panel, the element picker changes behavior and allows to pick "accessible" elements from the page instead of just any DOM node.
So I think the way forward would be to create some DevTools webextension API that allows any panel to do this too.

(In reply to Hubert B Manilla from comment #4)
> - One point is the fact that the element picker is positioned in place that
> gives the impression that it can be used across any of the panels (if it was
> only meant for the inspector it should probably sit within the inspector)
The element picker is such a common thing people use that it just makes more sense at the top level. It used to be in the inspector panel years ago, and we moved it.
If we're able to add some API for panels to hook on it to change its behavior, then staying at the top level makes sense too.

> Possible Solutions
> - Do what chrome does.
So, I don't see any reason so far *not* to do this. Victoria and I just mentioned it may feel weird, but aligning with Chrome for now would be ok. I see this as a good first step that we would then need to build upon with the API idea.

Comment 8

[Victoria Wang [:victoria]]

I like the idea of moving in the direction of the picker becoming more powerful and staying a top-level tool. Aligning with Chrome as a first step seems fine to me. 

I noticed that in Chrome, when highlighting an element (e.g. the whole body in bugzilla), and maintaining that hover/highlight state until the point of clicking on a non-Elements tab, the page highlight inconsistently disappears. (It seems to always go away when switching to Performance, not always with the other tabs). Anyway, I think the highlight disappearing upon selecting tabs where it's not used seems like a good idea as it lessens the annoyance when the whole page is highlighted blue. 

Keeping the highlight when switching to panels where the picker is used would be nice, but that's more of a concern for when the picker has click-to-persist highlight.

Comment 9

[Hubert B Manilla]

(In reply to Patrick Brosset <:pbro> from comment #7)
> (In reply to Hubert B Manilla from comment #5)
> > i think my main point would be having to implement an element picker
> > functionality in a devtool extension when the native one can be used.
> That's a very good point. Extensions that (in some way) select elements in
> the page should have the ability to rely on a similar UX than that of the
> element picker. Now, we did precisely this for the new accessibility tools
> (which I think shipped with Firefox 61, and need to be enabled from the
> settings panel first). When you switch to that panel, the element picker
> changes behavior and allows to pick "accessible" elements from the page
> instead of just any DOM node.
> So I think the way forward would be to create some DevTools webextension API
> that allows any panel to do this too.
Excellent idea!!

> (In reply to Hubert B Manilla from comment #4)
> > - One point is the fact that the element picker is positioned in place that
> > gives the impression that it can be used across any of the panels (if it was
> > only meant for the inspector it should probably sit within the inspector)
> The element picker is such a common thing people use that it just makes more
> sense at the top level. It used to be in the inspector panel years ago, and
> we moved it.
> If we're able to add some API for panels to hook on it to change its
> behavior, then staying at the top level makes sense too.
> 
> > Possible Solutions
> > - Do what chrome does.
> So, I don't see any reason so far *not* to do this. Victoria and I just
> mentioned it may feel weird, but aligning with Chrome for now would be ok. I
> see this as a good first step that we would then need to build upon with the
> API idea.
Yes this would be a good first step!

Thanks!!! :)

I'm interested in helping out to get these fixed!

Comment 10

[Patrick Brosset <:pbro>]

(In reply to Hubert B Manilla from comment #9)
> I'm interested in helping out to get these fixed!
Great! I believe the code that switches to the inspector early when clicking on the picker icon is inside this function: https://searchfox.org/mozilla-central/rev/d2966246905102b36ef5221b0e3cbccf7ea15a86/devtools/client/framework/toolbox-highlighter-utils.js#107-134
If we remove it from there, we'll need to switch to the inspector in stopPicker instead I guess.