976724 - With <input type="color"> on Mac OS X, when color picker is redirected away from an <input> (by clicking another one), you can't make it target the original <input> again

Status: RESOLVED DUPLICATE of bug 975468

(Core :: Widget: Cocoa, defect)

Description

[Daniel Holbert [:dholbert]]

+++ This bug was initially created as a clone of Bug #975468 +++

Spinning off one part of bug 

Steps to reproduce:

1) open a document with two <input type="color">s, e.g. attachment 8379839 [details]

2) click on the first <input>; the Mac OS X color picker appears;

3) without closing the color picker, select the second <input>. Note that you can now customize *its* color.  (Ignore the fact that the first input oddly copies the second input's color at this point; that's covered by bug 975468.)

4) without closing the color picker, select the first <input> again. Try to customize its color.

EXPECTED RESULTS:
 - The color picker should end up allowing you to customize the first <input>.
(Depending on how strict we want to be, perhaps it should never even change away from the first <input>)

ACTUAL RESULTS:
After step 4, the color picker dialog is still controlling the *second* input. i.e. when you click the second <input>, we successfully retarget the color picker dialog to that <input>. BUT, we fail to retarget it back to the first <input> when you click the first input again.

Regression range:
{
Last good revision: 42b2a2adda8f (2013-12-07)
First bad revision: edac8cba9f78 (2013-12-08)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=42b2a2adda8f&tochange=edac8cba9f78
}

--> Looks like a regression from bug 946479.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> --> Looks like a regression from bug 946479.

(No big surprise, but this was confirmed when I let mozregression continue bisecting through mozilla-inbound builds. It produced this regression range:
{
Last good revision: 6aca1511c1bb
First bad revision: ccba2b6b092d
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6aca1511c1bb&tochange=ccba2b6b092d
}
which contains only bug 946479's commit.

Comment 2

[Daniel Holbert [:dholbert]]

baku, any chance you have cycles to take a look at this? Per bug 975468 comment 10, we may block enabling <input type="color"> on Mac until this (and/or several other related bugs) are fixed.

Comment 3

[Andrea Marchesini [:baku]]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> baku, any chance you have cycles to take a look at this? Per bug 975468
> comment 10, we may block enabling <input type="color"> on Mac until this
> (and/or several other related bugs) are fixed.

This seems to be a bug in the colorPicker cocoa implementation.
I don't have a mac. I can see if I can find one, but probably it's better to assign it to a mac developer.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Since we backed this out of 28, not tracking there (and marking unaffected) but we'll want this for shipping it in FF29.

Comment 5

[Arnaud Bienner]

Same root cause as bug 975468, which is fixed now.