Closed Bug 976724 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 975468
Tracking Status
firefox28 - unaffected
firefox29 --- affected
firefox30 --- affected

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: regression)

+++ 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.
Version: 28 Branch → Trunk
(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.
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.
Flags: needinfo?(amarchesini)
(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.
Flags: needinfo?(amarchesini)
Since we backed this out of 28, not tracking there (and marking unaffected) but we'll want this for shipping it in FF29.
Same root cause as bug 975468, which is fixed now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 975468
You need to log in before you can comment on or make changes to this bug.