895464 - Implement ColorPicker for WinRT widget backend

Status: RESOLVED WONTFIX

(Core Graveyard :: Widget: WinRT, defect, P3)

Description

[Jim Mathies [:jimm]]

See bug 875754.

Comment 1

[Daniel Holbert [:dholbert]]

As noted in bug 930277 comment 20: unlike Android and B2G, metro can't easily be opted out from the forms.css styling for input[type="button"], since there's no preprocessor macro for "are we currently running in metro mode".

So: to enable input type="color" on windows (in that bug), we're going to enable the button styling on Metro as well, even though we'll be preffing off the actual button functionality in metro.js.  This means <input type="color"> will render like <input style="-moz-appearance: button">, basically, instead of the fallback textbox look-and-feel. (It'll behave like a textbox, but it'll be themed like a button.)

So, that makes this bug a bit higher-priority. Or rather, it means we need to do one of the following before bug 930277 hits release users:
 (1) Fix this bug (giving us an actual metro colorpicker backend)
or
 (2) Figure out a way to do "%ifdef METRO" in a useful way, in forms.css, so that Metro gets the correct fallback

(or (3) Decide that we're fine with Metro having a slightly quirky fallback UI for <input type="color">)

Jimm, do you have any suggestions on how to achieve (1) or (2)?

Note that Arnaud doesn't have Win8 available, so he can't implement this.  But if someone from the Metro team could provide the platform-specific "spawn a popup with this content which will need to return a string to the host page" boilerplate (or something approximately equivalent) I'll bet Arnaud would be open to write some simple HTML that we could use in that dialog.

Comment 2

[Jim Mathies [:jimm]]

(In reply to Daniel Holbert [:dholbert] from comment #1)
>  (1) Fix this bug (giving us an actual metro colorpicker backend)
> or
>  (2) Figure out a way to do "%ifdef METRO" in a useful way, in forms.css, so
> that Metro gets the correct fallback
> 
> (or (3) Decide that we're fine with Metro having a slightly quirky fallback
> UI for <input type="color">)

1 relies on some backend work for multiple views, plus a xul based touch centric color picker, so I would look for a way to do 2. There's probably a way to selectively override css in toolkit somehow, but I am not the guy to ask. (dolske, neil, en, gavin, & dao are possible suspects that might know)

Comment 3

[Daniel Holbert [:dholbert]]

OK. I filed bug 932066 on doing (2), so that we can keep this bug focused on (1) (when we're ready).

Comment 4

[Arnaud Bienner]

I tested input type color on Windows 8 using Chrome and it uses the native Windows color picker popup (the same as in non-Metro mode, the same we currently use).
Not sure how it is handled behind, but it sounds like we don't need to reimplement a color picker and we can probably use nsColorPicker also in Metro mode.

I still don't have a Windows 8 machine so I would be glad if someone can have a look at this and test it.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Arnaud Bienner from comment #4)
> I tested input type color on Windows 8 using Chrome and it uses the native
> Windows color picker popup (the same as in non-Metro mode, the same we
> currently use).
> Not sure how it is handled behind, but it sounds like we don't need to
> reimplement a color picker and we can probably use nsColorPicker also in
> Metro mode.
> 
> I still don't have a Windows 8 machine so I would be glad if someone can
> have a look at this and test it.

For metro I'd prefer we not use the old windows desktop dialog picker. Something integrated with the browser and touch friendly is what we're looking for.

Comment 6

[Arnaud Bienner]

(In reply to Jim Mathies [:jimm] from comment #5)
> For metro I'd prefer we not use the old windows desktop dialog picker.
> Something integrated with the browser and touch friendly is what we're
> looking for.

Sure. But waiting for something better, and considering input type color is activated by default now in nightly builds, IMHO it would be great to have something working instead of nothing, even if it's a temporary solution, don't you think?

Comment 7

[Jim Mathies [:jimm]]

(In reply to Arnaud Bienner from comment #6)
> (In reply to Jim Mathies [:jimm] from comment #5)
> > For metro I'd prefer we not use the old windows desktop dialog picker.
> > Something integrated with the browser and touch friendly is what we're
> > looking for.
> 
> Sure. But waiting for something better, and considering input type color is
> activated by default now in nightly builds, IMHO it would be great to have
> something working instead of nothing, even if it's a temporary solution,
> don't you think?

Not really. Temporary work arounds tend to become permanent features.

Comment 8

[Tim Nguyen :ntim]

(In reply to Arnaud Bienner from comment #4)
> I tested input type color on Windows 8 using Chrome and it uses the native
> Windows color picker popup (the same as in non-Metro mode, the same we
> currently use).
> Not sure how it is handled behind, but it sounds like we don't need to
> reimplement a color picker and we can probably use nsColorPicker also in
> Metro mode.
> 
> I still don't have a Windows 8 machine so I would be glad if someone can
> have a look at this and test it.

Chrome now uses a custom color picker in "Metro" mode.