Closed Bug 6881 Opened 25 years ago Closed 25 years ago

[PP] Native html checkboxes in a XUL file misbehave on unix

Categories

(Core :: Layout: Form Controls, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 6159

People

(Reporter: paulmac, Assigned: ramiro)

Details

I am unable to set any prefs that rely on checkboxes on 5/20 unix builds. This may already be known, but I am just noticing it, and can't find a bug on it. To reproduce: 1. Open Preferences 2. Goto Advanced Pane and uncheck Automatically prefill usernames and passwords. 3. Close Preferences 4. Open Preferences and go back to Advanced Pane. Results: Box reverts back to previous state, is checked. Expect Results: Pref should be 'sticky' and still be unchecked. Does not happen on mac/windows. Setting prefs like the default home page work correctly, so it looks like a problem with checkboxes on Unix maybe.
Priority: P3 → P1
Target Milestone: M6
John, didn't this work before?
The only panel that I actually know to have been working were Appearance and proxies (matt, do you have any idea on this?).
Status: NEW → ASSIGNED
Won't be fixing this for M6, since I'm still stuck on the XPCOM 2.0 reorg work.
Target Milestone: M6 → M7
Target Milestone: M7 → M6
The Appearances Pane exhibits the same behavior. If you check, say Messenger, then hit OK and come back, it will revert back to unchecked.
i looked at the old unix builds and it looks like prefs checkboxes never stuck on linux
Actually, I went back and used the 042709 build and checkboxes worked fine in prefs and were sticky. Matt, I expect a little better work from an x-QA'er.
Well yes, Matt. Go and stand in the corner. Actually, I did test this myself about a month ago, on Linux, and it worked then (at least, the "Appearance" panel did). The trouble with this bug is that it is specified using an obscure checkbox on an obscure panel, one which I certainly never tried before. I hope to get out of this xpcom2.0 hell within 24 hours, and have a chance to do some real work again.
Well, I see that PaulMac moved this back to M6. I still can't work on it for at least another day.
I really think we should later this bug to M7 since I'm going to be replacing all the prefs with xul anyways and we are going to run into even more of these problems. So i tried 3 different builds and all of them didn't work. I guess i should have tried 4 :-)
Target Milestone: M6 → M7
yes, the activity log says that I changed it to M6, but I actually don't remember doing that. Actually, I think we made comments to the bug at almost the exact same time, and since I did it right after yours, (and had left it at M6) it changed it from M7 back to M6. I will now change it back to M7.
OS: Windows 95 → Linux
Assignee: mcmullen → ramiro
Status: ASSIGNED → NEW
Component: Pref UI → Widget Set
Summary: [PP] Prefs set via UI (checkboxes) not sticky on Unix → [PP] Native html checkboxes in a XUL file misbehave on unix
So, I have to thank Seth Spitzer for helping me track this down. This bug occurs only with NATIVE widget checkboxes which are <html:input type = checkbox>. Even then, they work, but the visual feedback leads you to click twice... To reproduce: Bring up the prefs window (Edit/Preferences). By default, it opens at the appearance panel (chrome:/pref/content/pref-appearance.xul). Note that there are four checkboxes (hereinafter called "boxes" to save typing), which are correctly initialized to show the preferences. By default, box 1 is on, boxes 2-4 are off. Click ONCE on box 2 (or any unchecked box). The expected result is that it should show as checked (depressed, in my version of Linux). However, what actually happens is that this first click merely produces a square outline around the box, which appears to remain unchecked. If you click "OK" now, the pref will be changed with the value "true", despite the fact that the box is outlined (instead of checked). What people have been doing, upon seeing that the checkbox still appears unchecked after the first click, is clicking a second time. However, while this makes the checkbox change to a checked appearance, its value is apparently reset to 0. You need to trust your fingers and not your eyes! If you set your preference to: user_pref("nglayout.widget.mode", 2) so that you get gfx widgets, then everything works beautifully. So, since this bug concerns only native widgets on unix, I am reassigning this to ramiro (at sspitzer's suggestion). I'll bet it is a duplicate. Changing the component to "widget set".
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Im pretty sure this is a dup of 6159. *** This bug has been marked as a duplicate of 6159 ***
Status: RESOLVED → VERIFIED
Dupe it is then.
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
You need to log in before you can comment on or make changes to this bug.