Closed Bug 24598 Opened 26 years ago Closed 25 years ago

Textfields in prefs UI blank until clicked

Categories

(SeaMonkey :: Preferences, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 37650

People

(Reporter: tever, Assigned: mcafee)

Details

Overview Description: Text preferences not displayed in pref dialog until selected with mouse. Steps to Reproduce: sallet cacheset 1.) Select edit - preferences 2.) Select for example Advanced - Cache 3.) Click on "Memory Cache: ____ KBytes" edit box Actual Results: Text (possibly 1024 for this example) will appear only when edit box selected. Expected Results: Default values should be visible upon entry to the dialog box. Build Date & Platform Bug Found: 2000012008 NT Additional Builds and Platforms Tested On: Also fails on todays mac and linux builds Additional Information: This happens everywhere auto fill edit boxes appear in preferences.
re-assigning to self
QA Contact: sairuh → tever
re-assigning to self
OS: Windows NT → All
m15 for starters
Target Milestone: M15
Component: Pref UI → Preferences
Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.
Move to M16 for now ...
Target Milestone: M15 → M16
Reassigning for Don
Assignee: matt → mcafee
Target Milestone: M16 → M17
resummarizing
Summary: Text preferences not displaying properly → Textfield prefs contents display only after clicked
nominating nsbeta2
Keywords: nsbeta2
Yes I would strongly push for us to fix this for beta2, it makes the prefs very confusing otherwise. None of the data in the text fields ever shows up. Thanks, Vishy.
Severity: major → critical
PDT needs a retest...does this occur with latest builds?
Whiteboard: [NEED INFO]
this still happens on all platforms as of today.
resummarizing, we don't need info, removing whiteboard status. It happens, we need to fix this.
Summary: Textfield prefs contents display only after clicked → Textfields in prefs UI blank until clicked
Whiteboard: [NEED INFO]
Move to M20 target milestone.
Target Milestone: M17 → M21
kin just fixed the very related bug 37650. kin -- any idea if this problem has the same root cause?
I'm pretty sure this is related to bug #37650. This bug seems to manifest itself in XUL TextFields because they use Attribute changes to set the contents of the TextField, while HTML Form TextFields use SetProperty(). I'll verify this bug is fixed when my build is done today.
I just verified that this no longer occurs with my fix for bug #37650. Duping the bug to 37650 since that has the nsbeta2+ status already set. *** This bug has been marked as a duplicate of 37650 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Target Milestone: M21 → M16
agreed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.