Open Bug 856016 Opened 11 years ago Updated 2 years ago

Add a dedicated option for selecting the default color if a colorpicker is tied to a preference

Categories

(Toolkit :: UI Widgets, enhancement)

enhancement

Tracking

()

People

(Reporter: rsx11m.pub, Unassigned)

Details

Observed in Thunderbird bug 845807 comment #71, but equally applicable to any XUL application. To reproduce the problem,

 - Open the Content/Display/Appearance preferences in a Mozilla application;
 - select the Colors window or tab;
 - change, e.g., the "Unvisited link" color with the colorpicker;
 - now, open the colorpicker again and try to reset it back to the default;
 - unless it's a main color, virtually impossible to find a match.

In the given case of unvisited/visited link colors, the default colors are not even present in the standard palette.

Proposed solution:

 - If the colorpicker is within the scope of a prefwindow,
     AND the preference attribute points to a valid preference,
     AND a value is defined in the "defaults" preference branch.

 - then add (e.g., at the bottom) another row showing something like
     [color] default

 - and upon selection, reset the related user pref value.

This would make resetting colors to their defaults much easier.

An attribute "defaultcolor" could be added to define an explicit value for the default element, and to us defaultcolor="none" to switch off the feature.
I think the real problem is that the color picker is nothing more than a fixed color palette. Even mspaint from the '90s was more advanced.

This would be an excellent opportunity to implement a true RGB/HSL picker. IIRC it's simply an XBL binding, so I'd think it should be easily replaceable.

I'm not saying it wouldn't be nice to have a way to reset the picker to the default color. But on the other hand, there isn't a UI to do that for any other preference, so I'm not sure why the color picker should get special accommodations.
(In reply to Matthew Turnbull [Bluefang] from comment #1)
> I think the real problem is that the color picker is nothing more than a
> fixed color palette. Even mspaint from the '90s was more advanced.

There are plenty of bugs out there already on the colorpicker, see bug 42894 and others referencing to or from it. This bug here is specifically on the inability to see and select the default color, which is a very tiny subset of what the other bugs ask for (and which haven't seen much action at all).

> This would be an excellent opportunity to implement a true RGB/HSL picker.
> IIRC it's simply an XBL binding, so I'd think it should be easily
> replaceable.

Exactly, that's what I have in mind here, to add another field and method for this
in toolkit/content/widgets/colorpicker.xml which would extent that XUL palette.

> I'm not saying it wouldn't be nice to have a way to reset the picker to the
> default color. But on the other hand, there isn't a UI to do that for any
> other preference, so I'm not sure why the color picker should get special
> accommodations.

Because no other pref widget (like checkboxes or radiogroups) comes with a pop-up to select from. It's not unusual to cover a special case for a complex widget in a dedicated field like that elsewhere, and the user may expect to see such an option in this popup. I'm aware that this might be an interim solution until a more powerful colorpicker has been implemented, but this should be a low-hanging fruit to improve the existing colorpicker.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.