425564 - colorpicker's "disabled" property has no effect

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

I'm not sure if this is a widget bug or a docs bug, but the XUL reference says the "disabled" property of the colorpicker widget gets and sets the value of the "disabled" attribute <http://developer.mozilla.org/en/docs/XUL:colorpicker#p-disabled>, yet that doesn't work.

Getting and setting the attribute directly does work, however.  So either the property needs to be fixed, if there is such a property, or the docs need to be updated to remove the reference to it (and tell authors to get and set the attribute itself).

Comment 1

[Neil Deakin]

Looks like the button type of colorpicker just needs to extend 'chrome://global/content/bindings/general.xml#basecontrol' as the non-button type does.

In general, the colorpicker itself is in dire need of much love.

Comment 3

[[e-mail]]

Attachment: Proposed patch

As it happens I'd already discovered the bug reviewing the patch to bug 79603.

Comment 4

[[e-mail]]

Attachment: With tests!

Comment 5

[Ian Neal]

Would skins/themes need colorpicker[disabled="true"], colorpicker[disabled="true"]:hover:active style rules once this bug is fixed?

Comment 6

[Karsten Düsterloh]

> Would skins/themes need colorpicker[disabled="true"],
> colorpicker[disabled="true"]:hover:active style rules once this bug is fixed?

Yes, having several colorpickers on one page where some work and some don't, but all look alike, is not very helpful...

Comment 7

[[e-mail]]

Comment on attachment 313469 [details] [diff] [review]
With tests!

This patch exists solely to fix the accessibility and functionality issues raised in the bug. CSS updates would probably need to be addressed on a per-theme bases in separate bugs.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 313469 [details] [diff] [review]
With tests!

a=beltzner, hooray tests!

Comment 9

[[e-mail]]

Fix checked in.