Last Comment Bug 864254 - disable some more options in preferences dialog according to the state of options they are dependent on
: disable some more options in preferences dialog according to the state of opt...
Status: RESOLVED FIXED
: polish, ux-error-prevention, ux-visual-hierarchy
Product: Thunderbird
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- minor (vote)
: Thunderbird 24.0
Assigned To: :aceman
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-22 01:23 PDT by :aceman
Modified: 2013-10-22 11:59 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (13.45 KB, patch)
2013-04-23 15:20 PDT, :aceman
no flags Details | Diff | Review
patch v2 (10.86 KB, patch)
2013-04-26 12:44 PDT, :aceman
mkmelin+mozilla: review+
bwinton: ui‑review+
Details | Diff | Review

Description :aceman 2013-04-22 01:23:23 PDT
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?
Comment 1 :aceman 2013-04-22 01:24:51 PDT
Should have been:
Any ideas why ANY of these should not be done?
Comment 2 Magnus Melin 2013-04-22 04:10:00 PDT
Re language: i suppose that's still the default language for manual spell-check invocation.
Comment 3 :aceman 2013-04-22 04:53:23 PDT
Thanks. Maybe we could mention that in the panel?
Comment 4 :aceman 2013-04-23 15:20:44 PDT
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.
Comment 5 rsx11m 2013-04-23 15:32:26 PDT
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.
Comment 6 Richard Marti (:Paenglab) 2013-04-23 23:31:13 PDT
(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.
Comment 7 :aceman 2013-04-23 23:35:11 PDT
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.
Comment 8 rsx11m 2013-04-24 10:18:46 PDT
> 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.
Comment 9 :aceman 2013-04-26 12:42:52 PDT
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.
Comment 10 :aceman 2013-04-26 12:44:03 PDT
Created attachment 742516 [details] [diff] [review]
patch v2
Comment 11 Magnus Melin 2013-04-27 04:11:51 PDT
Comment on attachment 742516 [details] [diff] [review]
patch v2

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

LGTM! r=mkmelin
Comment 12 Blake Winton (:bwinton) (:☕️) 2013-06-16 11:49:42 PDT
Comment on attachment 742516 [details] [diff] [review]
patch v2

I agree with Magnus.  ui-r=me.  :)
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-06-18 08:40:33 PDT
https://hg.mozilla.org/comm-central/rev/99d7494dcc96
Comment 14 Javi Rueda 2013-10-22 11:12:16 PDT
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.
Comment 15 :aceman 2013-10-22 11:59:40 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.