Closed Bug 86899 Opened 25 years ago Closed 25 years ago

Send this email address as anonymous FTP password is not greyed out when box is unchecked

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: andre.bugs2, Assigned: bugzilla)

Details

(Keywords: polish, Whiteboard: fix in hand)

Attachments

(1 file)

[Tested with Build 2001-06-20-17 on Linux, but this has been here for ages] The textbox under the label "Send this email address as anonymous FTP password", under Advanced in Preferences, is not greyed out when the checkbox is unchecked. It is read-only, but it should also be grayed out to clearly show that text cannot be typed into it. Steps to reproduce: 1) Open Preferences and click on the Advanced category 2) Check and uncheck the anonymous FTP password checkbox Result: The textbox is not "greyed out" when the checkbox is unchecked. Expected result: Apart from being read-only (which it is) the textbox should also be greyed out to indicate that text cannot be typed into it.
also see this on winnt and mac, as well as both themes. not sure who should get this...trying blake for now. as tangent, in the Mail and Newgroups toplevel panel, there's a similar situation when you deselect the "When mail launches, show the Start Page..." checkbox: the Location textfield isn't disabled. the difference, however, is that the Location textfield here is editable. jglick/nbaca, i'm just curious, but is that field supposed to be editable even if the checkbox is not checked?
Assignee: asa → blake
Severity: normal → minor
Keywords: polish
OS: Linux → All
Hardware: PC → All
>is that field supposed to be editable even if the checkbox is not checked? sairuh, I believe you are correct, text field should be disabled if checkbox is unchecked.
filed bug 86986 for the Mailnews pref panel issue.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
Could someone explain to me why the below patch makes a difference? Note: the extra "field.disabled = !checked;" oddly enough needs to be there, otherwise the textbox will be non-editable even when it's not greyed out. Also note that the initial state of the textbox and checkbox seams to be wrong, so you have to click on the checkbox twise to see the textbox's state change. I know this patch is probably not of much help, but at least it shows what code needs to be changed. Index: pref-advanced.xul =================================================================== RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/content/pref-advanced.xul,v retrieving revision 1.54 diff -u -r1.54 pref-advanced.xul --- pref-advanced.xul 2001/06/20 05:51:44 1.54 +++ pref-advanced.xul 2001/06/21 10:44:07 @@ -46,6 +46,10 @@ { var checked = document.getElementById("advancedMailFTP").checked; var field = document.getElementById("advancedMailFTPAddress"); + if (checked) + field.setAttribute("disabled", "false"); + else + field.setAttribute("disabled", "true"); field.disabled = !checked; }
Attached patch patch — — Splinter Review
r=kerz
Whiteboard: fix in hand
I just tried this patch on top of 2001-06-22-00 and it worked exactly as expected. Thanks Blake!
Please don't apply this fix. It doesn't resolve the actual problem which is that the disabled property doesn't make the textbox appear disabled. The disabled property is proxied on to the internal html input which then sets the disabled attribute on itself. It is this that should be styled in the skins.
Or the disabled attribute should be set by the property as well as being proxied.
I already checked it in. Yes, I know you could take either approach -- style based on the state of the anonymous input, or just set the attribute in the property getter/setter (both seems like overkill). I asked Ben beforehand, and he said to just set the property.
So this means that every time that someone wants to disable a textbox they have to do it twice?
No, why would it mean that? It means that you can use .disabled or setAttribute("disabled", "true") and the styling will be correct.
Sorry for all the spam caused entirely by a misunderstanding on my part.
I checked this in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
trunk-only fix. vrfy'd fixed using 2001.07.11.xx-trunk comm bits on linux, winnt and mac [and both themes, just to be sure].
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: