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

Status: VERIFIED DUPLICATE of bug 6159

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

Description

[Paul MacQuiddy]

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.

Comment 1

[don]

John, didn't this work before?

Comment 2

[mcmullen]

The only panel that I actually know to have been working were Appearance and
proxies (matt, do you have any idea on this?).

Comment 3

[mcmullen]

Won't be fixing this for M6, since I'm still stuck on the XPCOM 2.0 reorg work.

Comment 4

[Paul MacQuiddy]

The Appearances Pane exhibits the same behavior. If you check, say Messenger,
then hit OK and come back, it will revert back to unchecked.

Comment 5

[matt]

i looked at the old unix builds and
it looks like prefs checkboxes never stuck
on linux

Comment 6

[Paul MacQuiddy]

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.

Comment 7

[mcmullen]

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.

Comment 8

[mcmullen]

Well, I see that PaulMac moved this back to M6. I still can't work on it for at
least another day.

Comment 9

[matt]

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 :-)

Comment 10

[Paul MacQuiddy]

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.

Comment 11

[mcmullen]

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".

Comment 12

[ramiro]

Im pretty sure this is a dup of 6159.

*** This bug has been marked as a duplicate of 6159 ***

Comment 13

[cpratt]

Dupe it is then.

Comment 14

[leger]

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.