disable some more options in preferences dialog according to the state of options they are dependent on

RESOLVED FIXED in Thunderbird 24.0

Status

Thunderbird
Preferences
--
minor
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: aceman, Assigned: aceman)

Tracking

({polish, ux-error-prevention, ux-visual-hierarchy})

Trunk
Thunderbird 24.0
polish, ux-error-prevention, ux-visual-hierarchy

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

10.86 KB, patch
Magnus Melin
: review+
bwinton
: ui-review+
Details | Diff | Splinter Review
(Assignee)

Description

4 years ago
I have identified that these dependent disabling can be done:
Composition -> Addressing:
- disable address book dropdown when "Automatically add outgoing e-mail addresses to my:" is unchecked.

Composition -> Spelling:
- disable language dropdown when both spelling options are unchecked.

General:
- disable "Location" textbox when "When TB launches, show start page in the message area" is unchecked.
- disable the "Customize" button, when "Show an alert" is unchecked.

Display -> Formatting -> Colors...:
- disable "text" and "background" color pickers if "Use system colors" is checked. Are these really exclusive?

Attachments -> Outgoing:
- disable the numeric widget when "Offer to share for file larger than" is unchecked.
Also I am not sure if the "share" word is appropriate here as we want to only show the attachment to the recipient not any more public type of sharing.

Any ideas why on of these should not be done?
(Assignee)

Comment 1

4 years ago
Should have been:
Any ideas why ANY of these should not be done?
Summary: disable some more options in preferences dialog according to the state of other options → disable some more options in preferences dialog according to the state of options they are dependent on

Comment 2

4 years ago
Re language: i suppose that's still the default language for manual spell-check invocation.
(Assignee)

Comment 3

4 years ago
Thanks. Maybe we could mention that in the panel?
(Assignee)

Comment 4

4 years ago
Created attachment 741055 [details] [diff] [review]
patch

So this seems almost done. There is one problem: there seems to be no style for a disabled <colorpicker> . I have not yet got a reply from toolkit guys.
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED

Comment 5

4 years ago
There are some Toolkit definitions for disabled colorpickers for in-content UI,
> http://mxr.mozilla.org/comm-central/search?string=colorpicker&find=inContentUI.css

Mostly just graying the text color and applying some transparency. I'm wondering why such definitions weren't made in the global/colorpicker.css files.
(In reply to rsx11m from comment #5)
> There are some Toolkit definitions for disabled colorpickers for in-content
> UI,
> > http://mxr.mozilla.org/comm-central/search?string=colorpicker&find=inContentUI.css
> 
> Mostly just graying the text color and applying some transparency. I'm
> wondering why such definitions weren't made in the global/colorpicker.css
> files.

The buttons have already -moz-appearance: button; and disable="true" let them appear disabled. What's needed is something like:

colorpicker[type="button"][disbled="true"] > .colorpicker-button-colorbox {
  opacity: 0.6;
}

A new bug for this may be worth it.
(Assignee)

Comment 7

4 years ago
Comment on attachment 741055 [details] [diff] [review]
patch

OK, so let's see if the disabling code is actually accepted and then we can file the theme change.
Attachment #741055 - Flags: ui-review?(bwinton)
Attachment #741055 - Flags: review?(mkmelin+mozilla)

Comment 8

4 years ago
> Display -> Formatting -> Colors...:
> - disable "text" and "background" color pickers if "Use system colors" is checked.

Is it possible for the system color lookup to fail? If yes, the colorpickers would determine the fallback colors. If some system color is always defined and a fallback never occurs, disabling the colorpickers is the right thing to do.
(Assignee)

Comment 9

4 years ago
Good point. The code is in /mozilla and I could not see easily if it can fail. 
It seems Firefox has the same dialog and also does not have the disabling.
So I will remove it.
(Assignee)

Comment 10

4 years ago
Created attachment 742516 [details] [diff] [review]
patch v2
Attachment #741055 - Attachment is obsolete: true
Attachment #741055 - Flags: ui-review?(bwinton)
Attachment #741055 - Flags: review?(mkmelin+mozilla)
Attachment #742516 - Flags: ui-review?(bwinton)
Attachment #742516 - Flags: review?(mkmelin+mozilla)

Comment 11

4 years ago
Comment on attachment 742516 [details] [diff] [review]
patch v2

Review of attachment 742516 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM! r=mkmelin
Attachment #742516 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 742516 [details] [diff] [review]
patch v2

I agree with Magnus.  ui-r=me.  :)
Attachment #742516 - Flags: ui-review?(bwinton) → ui-review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/99d7494dcc96
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0

Comment 14

4 years ago
While working on bug 601263, I was looking at the Error Console. When General pane is opened -every time, in fact- an error is logged into it.

Code in function updateCustomizeAlert() in general.js is refering to the customizeMailAlert button which in Mac OS X is not present. There is a #ifdef: http://mxr.mozilla.org/comm-central/source/mail/components/preferences/general.xul#69.
(Assignee)

Comment 15

4 years ago
This bug is already fixed. Please file your problem as a new bug and I'll look into it. Please CC me on the bug, thanks.
You need to log in before you can comment on or make changes to this bug.