Open Bug 869116 Opened 11 years ago Updated 4 years ago

For preference options with value, make sure that labels are consistently grayed when locked

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set
minor

Tracking

(Not tracked)

People

(Reporter: rsx11m.pub, Unassigned, Mentored)

Details

(Keywords: good-first-bug, Whiteboard: [lang=xul/js])

Per discussion in bug 867210 comment #24 and following, the behavior of preference-pane constructs like

  [x] Do this or that for [__] seconds/MB/etc.

that combine a checkbox or radiogroup with a (usually numerical) textbox (for a value valid for this specific option only) is inconsistent when the main preference is locked.

Steps to reproduce:
 1. In Edit > Preferences, find a setting with such a construct
 2. Follow http://kb.mozillazine.org/Locking_preferences
 3. Lock the preference associated with the checkbox or radiogroup
 4. Restart SeaMonkey and observe

In most cases, the label after the checkbox or radio element is grayed out but the label behind the textbox remains active. The desired behavior according to bug 867210 is that the display attribute of the label following the textbox is tied to the label of the governing checkbox or radio element.

In suite/mailnews/prefs/pref-viewing_messages.xul, this was accomplished by

>      <hbox align="center" class="indent">
>        <checkbox id="markAsReadAfterPreferences" ... />
>        <textbox id="markAsReadDelay" ... />
>        <label id="secondsLabel" ... >
>           <observes element="markAsReadAfterPreferences"
>                     attribute="disabled"/>
>        </label>
>      </hbox>

One can test the behavior if this construct with the following mozilla.cfg content to lock the checkbox:

> // lockPref() prefs here with a specific value
> lockPref("mailnews.mark_message_read.delay", true);

Note that the textbox remains intact (unless that preference is disabled as well) but the continuing label is grayed out along with the main label. The idea of this bug is to let the other instances follow that example.

Some special cases:

Browser preferences, main tab:
> lockPref("browser.sessionstore.max_concurrent_tabs", 3);

This will lock both the radiogroup as well as the textbox. Nothing can be done about it as those are tied to the same preference, bug 868486 may resolve this.

Privacy & Security > Cookies:
> lockPref("network.cookie.lifetimePolicy", 3);

This disables but doesn't gray out the textbox, which is unexpected (probably should go into a bug of its own).
This bug is looking for a mentor. RSX11M, would you be willing?
Flags: needinfo?(rsx11m.pub)
Whiteboard: [good first bug][lang=xul/js][mentor=?] → [good first bug][lang=xul/js][mentor needed]
I could (provided that I have time to spare when someone approaches this bug), but I'm neither a council member nor a module owner. Thus, I'm not sure if I qualify for that role.
Flags: needinfo?(rsx11m.pub)
(In reply to rsx11m from comment #2)
> I'm neither a council member nor a module owner. Thus, I'm not
> sure if I qualify for that role.

A mentor is just someone who guides someone else to work on a bug through the process, i.e. which parts to adapt and how, where to find information, how to create a patch, how to request review and from whom etc. No involvement in the "chain of command" required at all. In short: You certainly qualify. :-)
Well, let's give it a try then.  8-)
Mentor: rsx11m.pub
Whiteboard: [good first bug][lang=xul/js][mentor needed] → [good first bug][lang=xul/js]
Hi,
Can I take this bug?
Sure, thanks!
Assignee: nobody → melisa.cecilia.mail
Status: NEW → ASSIGNED
Melisa,

any news here?
Flags: needinfo?(melisa.cecilia.mail)
No response. Setting status to new.
Assignee: melisa.cecilia.mail → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(melisa.cecilia.mail)
Keywords: good-first-bug
Whiteboard: [good first bug][lang=xul/js] → [lang=xul/js]
You need to log in before you can comment on or make changes to this bug.