bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Don't enable element inspector and eyedropper at the same time




Developer Tools: Graphic Commandline and Toolbar
3 years ago
2 years ago


(Reporter: magicp, Unassigned)



Firefox Tracking Flags

(firefox46 affected, firefox47 affected, firefox48 affected, firefox49 affected)


(Whiteboard: [polish-backlog][difficulty=easy])


(1 attachment)



3 years ago
Created attachment 8645609 [details]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150809030213

Steps to reproduce:

1) Enable element inspector (Pick an element from the page)
2) Enable eyedropper (Grab a color from the page)
3) Move mouse pointer on the page

Actual results:

Eyedropper grabs a wrong color on the page, because canvas color was changed by element inspector.

Expected results:

When enable eyedropper, element inspector should be disabled. And also vice versa.


3 years ago
Component: Untriaged → Developer Tools
OS: Unspecified → All
Hardware: Unspecified → All

Comment 1

3 years ago
While I think that grabbing a blue color of highlighted box is a good opportunity (aka WYSIWYG), I completely agree that color element picker and eyedropper shouldn't interfere with each other.

Reproduced with these steps:
1.   Enable element inspector (Pick an element from the page)
2(+) Move mouse over an element on the page to highlight it
3.   Enable eyedropper (Grab a color from the page)
4(+) Move mouse over *chrome* content of devtools so that eyedropper circle appeared
5.   Move mouse pointer on the page   [I don't see element picker changing highligh until Step 6]
6(+) Quickly move mouse over the page   [Now I see elements being highlighted sometimes. So sometimes element picker is active and eyedropper is inactive, and sometimes - vice versa]

I can't reproduce "eyedropper grabs a wrong color on the page" if I skip Step 2 (in this comment) and just move mouse to eyedropper within devtools.
So that wysiwyg opportunity is a bit tricky, and removing it won't be a big loss.
Component: Developer Tools → Developer Tools: Graphic Commandline and Toolbar
Ever confirmed: true
Whiteboard: [polish-backlog]
Whiteboard: [polish-backlog] → [polish-backlog][difficulty=easy]

Comment 2

2 years ago
How about next steps?
Flags: needinfo?(pbrosset)
So we need to make sure that when the eyedropper tool is started, the element picker is canceled.
There are 3 ways of starting the eyedropper: 
- using the toolbar button
- clicking on a color swatch in the css rules-view and starting it from the color-picker panel
- going in the developer menu in the firefox menubar

I know that the toolbar button uses a gcli command file to open the eyedropper:
It would be easy from this command file to cancel the picker if it had been started before with something like:

let gBrowser = context.environment.chromeDocument.defaultView.gBrowser;
let target = TargetFactory.forTab(gBrowser.selectedTab);
let toolbox = gDevTools.getToolbox(target);
// If a toolbox exists
if (toolbox) {

But unfortunately, doing this would not solve the problem for when you start the eyedropper from the menu or the color-picker. For a solution to work in all cases, we'd have to modify the eyedropper code in:
And in particular, the Eyedropper.prototype.open function
The Eyedropper class has access to the reference of the chromeWindow (this._chromeWindow), so from this, it should be possible to write a similar piece of code than the one I wrote above to cancel the picker.
Flags: needinfo?(pbrosset)


2 years ago
See Also: → bug 1221996


2 years ago
Has STR: --- → yes
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
Version: 42 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.