244153 - Clicking on checkbox text shouldn't toggle the checkbox

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Gerald Vogt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7) Gecko/20040514

It happens to me all the time when I work too quickly: There is this warning
window coming up, for example, warning me that I am about to send unencrypted
data over the internet. All I want to do is to press "continue". Accidently,
when I move the mouse to the button and get too high and click on the text of
the checkbox. It immediatly notice that the click did not dismiss the dialog
window and move the mouse little bit lower onto the button and gone it is.

But what I did is actually turn off the messages completely. Finding the place
in the settings where I can turn them on again can sometimes be a quite time
consuming task.

What I would love to see is a seperation of the checkbox control itself and its
label text. Only the checkbox itself should switch it and the text after that
should be some insensitive label text. That way, if I really want to turn the
messages off, I can still do it, but not anymore by just slipping a little bit
too high over the continue button.

In addition, even nicer, at least for beginners, would be a second dialog window
telling people where to turn on the option again and if they are sure to change
it permanently now.

Reproducible: Always
Steps to Reproduce:
1. Send form data, pressing submit
2. See the warning window (accidentally) press onto the text of the checkbox
3. press "continue"

Actual Results:  
No more warning window.

Expected Results:  
Still the same warning window next time.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 3

[Andrew Schultz]

Mozilla isn't moving your mouse cursor to the button after you uncheck the box,
so, the expectation is that you'll undo it if you care.  The relevant checkboxes
I know of are all in privacy->SSL.

The only way this would happen is to do it for all checkboxes, which seems like
a bad idea.   

==> XUL widgets

Comment 4

[Gerald Vogt]

(In reply to comment #3)
> The only way this would happen is to do it for all checkboxes, which seems like
> a bad idea.   

Not for all checkboxes but for those, which will change some behaviour
permanently (until you find and change it in the options again) and which have a
button so closely below it. If you focus with your eyes on the button who don't
necessarily notice immediately that a click a little above the button (on the
checkbox text) does actually change the checkbox.

You don't have to change the checkbox widget. You just have to but a checkbox
without any label next to a static text. That should not be too hard to change
in the XUL.

Comment 5

[Andrew Schultz]

> You just have to but a checkbox without any label next to a static text.

That's a rather bad change.  All checkboxes should have labels for accessibility purposes if nothing else.  It's like images without alt attributes.

Comment 6

[Gerald Vogt]

(In reply to comment #5)
> That's a rather bad change.  All checkboxes should have labels for
> accessibility purposes if nothing else.  It's like images without alt
> attributes.

I think it's something completely different. The problem here is that the checkbox is "too" accessible. It is too easy to check a box when all you want to do it press the button. So from accessiblity point of view I think this kind of arrangement of checkbox with sensitive label and button below is the worst. If you have a hard time actually hitting the button you will a much harder time to deselect the checkbox if you have accidentally selected it (if you notice it).

Comment 7

[Andrew Schultz]

You misunderstand what I mean by accessibility.  Access for disabled people.  Keyboard-only and/or screen readers (for blind people).  They need to know what the checkbox is (which is the label's purpose in life).

Comment 8

[Gerald Vogt]

What about abandoning this checkbox thing and using three buttons like the firefox remember password thingy? Kindof "No", "Yes", and "Yes forever" depending on what the checkbox actually does...

Comment 9

[Tony Mechelynck [:tonymec]]

I agree with ajschult from the accessibility POV. If, in some dialog, the checkbox label is felt to be too near the OK and Cancel buttons, I suppose the right thing to do would be to file a bug about that particular dialog (and if several dialogs are affected, one separate bug for each of them, maybe in the UI or Themes components for the concerned Product); but in the general case, clicking a checkbox's label has always toggled that checkbox for as long as I can remember, and I believe changing that behaviour would trigger a waterfall of "regression" bugs.

I'm in favour of WONTFIXing this bug but I don't have the power to make that decision myself.

Comment 10

[Boris Zbarsky [:bzbarsky]]

For all checkboxes, this is certainly wontfix.  This was about an issue with a particular dialog, though, no?  So it should probably be moved to the appropriate UI component.

Comment 11

[Andrew Schultz]

WONTFIX-ing

if you think all of our dialogs with checkboxes should have additional buttons instead, you should probably propose that in the newsgroup (mozilla.dev.apps.seamonkey).

Comment 12

[Gerald Vogt]

This was and is not about SeaMonkey but about Firefox.

Comment 13

[Tony Mechelynck [:tonymec]]

(In reply to comment #12)
> This was and is not about SeaMonkey but about Firefox.

Wrong. Check the "Product" at top and the "User-Agent" and "Build Identifier" at the start comment #0 (UA and BI are about the Mozilla Suite actually, but SeaMonkey has inherited all the latter's specific bugs).