559506 - If you shift+click or ctrl+click on a label for a checkbox, checkbox is not checked.

Status: REOPENED

(Core :: DOM: Forms, defect)

Description

[Gordon Mei]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

If you shift+click on a label for a checkbox, the checkbox is not checked.  This is unlike any other browser I've come across, including other Gecko browsers like Camino.  Clicking without the shift modifier key on a label, on the other hand, behaves fine.

<input type="checkbox" class="checkboxclass" value="1" id="checkbox1" /><label for="checkbox1">Checkbox</label>

Reproducible: Always

Steps to Reproduce:
1. Click a checkbox's corresponding label to check and uncheck it. It toggles the checkbox checked and unchecked.
2. Shift+click a checkbox's corresponding label to check and uncheck it. It has no effect on the checkbox.
Actual Results:  
Shift+clicking a checkbox label does not check or uncheck the checkbox.

Expected Results:  
Shift+clicking a checkbox label should check/uncheck the checkbox.  See Camino 2.0.2 (1.9.0.18 2010021619), or Chrome 5.0.342.9, or Safari 4.0.5 for proper behavior.

Comment 1

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html

Comment 2

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 3

[Gethin Webster]

I can confirm that this is still broken in Firefox 6.0.2

http://jsfiddle.net/mhR9F/

Comment 4

[Kennith Grotjohn]

Attachment: testcase

Comment 5

[Kennith Grotjohn]

Bug still exists in FF 16.0.1

Comment 6

[zhouyanming]

Bug still exists in FF 21.0

Comment 8

[ballistichedonistic]

It would be great to get a fix for this as the prettified checkboxes created by the library at http://csscheckbox.com/ do not work when shift or ctrl is held when using the desktop version of Firefox 26.0 (current version). It does however work in current versions of Chrome and IE.

Comment 9

[George Mauer]

This is happening in version 29.0.1 on windows 8.1. Really annoying.

Reduced test case: http://jsfiddle.net/24aqv/3/

Comment 10

[Daniel Holbert [:dholbert]]

This behavior was added intentionally in bug 382369, as part of allowing text-selection inside of a <label>, since the "Shift+Click" action is reserved for adjusting the end of an existing selection.

The code was added here, in this changeset for bug 382369:
  http://hg.mozilla.org/mozilla-central/rev/934ae18dd58f#l2.95

And it currently lives here:
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLLabelElement.cpp?rev=6c1c7e45c902&mark=154-158#154

(Note that Ctrl+Click has similar results, too.)

Comment 11

[Daniel Holbert [:dholbert]]

It looks like Chrome ignores shift+click, for the purposes of checkbox-checking (like we do), *if* you have any text selected. Or something like that.

Maybe that's what we should do. (Adjusting the end of an existing selection isn't really meaningful if there is no selection.)

Comment 12

[George Mauer]

To be clear the use case I have is a long list of checkboxes and - as in the common ui metaphor - clicking one and shift-clicking into another should select all in between.

This is currently impossible to implement correctly, we have to rely on mouseup which makes interaction a bit weird.

Comment 13

[mcmics]

Still occurs wit hcurrent version (FF 62.0.2)

You can test it with the MDN example: https://developer.mozilla.org/de/docs/Web/HTML/Element/label

click label with alt or shift or ctrl. Checkbox event not fired

On other browsers (Chrome, Safari) it will works. 
The spec says: When a <label> is clicked or tapped and it is associated with a form control, the resulting click event is also raised for the associated control.

Comment 14

[jox]

We're also facing the problem (FF 62.0.3). In Chrome, Safari and Edge this is not an issue.

We have the same common use case as George Mauer: altering multiple checkbox states by selecting a range using click and shift-click.

We have even disabled user selection for the labels using css: "user-select: none".

Shift-clicking the checkboxes directly works as expected.

Here is a fiddle: https://jsfiddle.net/nf3yc2dL/

Comment 15

[Andrew Halberstadt [:ahal]]

I ran into this while trying to make a UI for bug 1499822.

Comment 16

[Marc]

Bug still exists in FF 70.0.1

Comment 17

[anantha]

Bug still occurs in FF 71.0

Comment 18

[Nicolas Hoffmann]

Bug still happen on FF 72.

This is really annoying when you use custom checkboxes by targetting the neighbor in CSS. For example, ProtonMail beta v4 is impacted, see https://design-system-beta.netlify.com/forms/

Comment 19

[alliz_gub]

Could be related to #764822 ?

Ctrl or Shift + Enter on an input field will not report the modifiers.

Comment 20

[alliz_gub]

bug 764822 for the link
http://jsfiddle.net/ReD6k for the fiddle, try to Shift+Click or Shift+Enter (with focus on input) to see the difference in the modifiers

Comment 21

[sergchernata]

This is still a problem in FF 84.

Same usecase as everyone above - custom checkboxes.

Comment 22

[alex.rothschild1]

Also an issue with the Alt key. Here's a fiddle - https://jsfiddle.net/rothschild86/y8hrxf06/10/

To test in FF - Press ALT, and click on the label Option (any). Click again to observe the effect - everything should work.

Now, remove the code past line 11. Repeat the test, see that the Alt-click no longer has any effect.

Notice, that the code still words fine with just the first 11 lines in Chrome.

Comment 23

[Stefan Weil]

This very old issue still exists with Firefox 125.0.1 on latest macOS.

Comment 24

[peter.makowski]

Attachment: bugfix.patch

Done

• Added HasSelection checking if there is an active text selection within the label.
• Adjusted the PostHandleEvent to account for shift+click behavior when there is no active selection.

Testing:

• Verify that clicking on a checkbox label toggles the checkbox.
• Click outside of the checkbox to start a selection. Verify that shift+click on a checkbox label allows to select text within the label and checkbox state remains unchanged.

Comment 25

[peter.makowski]

Attachment: shift-click-test-case.html

HTML test case to use with test steps described in the previous comment.

Comment 26

[Daniel Holbert [:dholbert]]

Thanks for the patch! Given that the changed files are in /dom rather than /layout, I'm going to reclassify this under the DOM forms component.

To get the patch-review process started -- we use phabricator for patch submission and code review (with a simple local utility called moz-phab to submit revisions from your local mercurial or git repo). Some instructions to submit a patch for review are here:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to-submit-a-patch

Could you take a look there and submit the patch using moz-phab?

(I'll go ahead and assign the bug to you, too, since I think phabricator might require that, for newish bugzilla accounts.)

Comment 27

[Daniel Holbert [:dholbert]]

Also: I'm not a reviewer for changes in /dom, but I'll leave a few drive-by review nits from glancing at the patch:

• Commit message should describe the change, e.g. "bug 559506: check for selection when handling shift+click on labels" or something along those lines
• The added #include statements should be inserted in alphabetically sorted order into the include list (as much as possible, the existing list isn't always well sorted)
• The added function-declaration bool HasSelection() should be inserted up alongside other function declarations, rather than after the member-variables.
• You don't need to null-check the result of nsPresContext* presContext = frame->PresContext(); -- presContext will always be null there. (We have a convention that getters-that-are-guaranteed-to-return-something-non-null skip the use of "Get", as in this case.)

Comment 28

[peter.makowski]

Attachment: Bug 559506: check for selection when handling shift+click on labels

• add HasSelection method to HTMLLabelElement
• update PostHandleEvent to consider active selection when handling shift+click events

Comment 29

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 30

[Andrew McCreight [:mccr8]]

Edgar, is this something we should land? It looks like it stalled out after the patch got reviewed. It has been awhile so it might need to be rebased. Thanks.

Comment 31

[Edgar Chen [:edgar]]

I will take a look.

Comment 32

[Kumi]

Any movement on this?