1513562 - Modifier key clicking on a label does not fire a change event on its input

Status: NEW

(Core :: DOM: Events, defect, P2)

Description

[alex.joseph.regan]

Attachment: onchange.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

When wrapping an input in a label, pressing modifer/meta keys while clicking on the label does not trigger change events on the input. This behavior is observed in Chrome and Safari on Mac and Linux, but not in Firefox on Mac or Linux (my two available platforms).

I have attached an html file that you can run in various browsers to reproduce this behavior. Note that the input is positioned off screen since this was part of my original use-case (creating something that looks like links, but can be toggled with assistive technology/keyboard), but may not be essential to the repro.

This seems potentially related to 1295719 (https://bugzilla.mozilla.org/show_bug.cgi?id=1295719)


Actual results:

Control/command clicking on the label fires the click event, but not the input change event.


Expected results:

Control/command clicking on a label wrapping an input should fire the input change event.

Comment 1

[Timea Cernea [:tbabos][inactive]]

Reproduced on Windows 10 x64 on all Firefox versions. Please note that compared to Chrome, the onclick element also changes to "LABEL" when using CTR+Click.

Comment 2

[Andreas Farre [:farre]]

Olli, what do you think?

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Andreas Farre [:farre] from comment #2)

Olli, what do you think?

Mirko, could you please investigate this?

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

I could reproduce. It's also happening with the <input> element being positioned on screen, which simplifies the example to reproduce this problem.

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Attachment: onchange-onscreen.html

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Observations: When clicking the label while having CTRL pressed:

• the 'checkedness' of the checkbox doesn't change (hence, no surprise, that no change event is fired).
• the event.target.tagName of the click event is "LABEL" (instead of "INPUT").

We need to check what the spec says about this.

Comment 7

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

I've checked the behavior on Windows: for both scenarios (click, CTRL + click), Firefox and Chrome behave like on Ubuntu/Linux.

That is, Chrome's and Firefox' behavior is consistent across platforms, but both Browsers behave differently.

Comment 8

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

The spec doesn't cover this problem properly. I've created https://github.com/whatwg/html/issues/4516 and https://github.com/whatwg/dom/issues/749 to fix that. Meanwhile, to achieve compatibility across browsers, it seems reasonable to adapt Firefox' code to also fire the change event when the "CTRL" (or another modifier) key is pressed.

Comment 9

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Mirko Brodesser from comment #8)

The spec doesn't cover this problem properly. I've created https://github.com/whatwg/html/issues/4516 and https://github.com/whatwg/dom/issues/749 to fix that. Meanwhile, to achieve compatibility across browsers, it seems reasonable to adapt Firefox' code to also fire the change event when the "CTRL" (or another modifier) key is pressed.

Masayuki: as you're more familiar with keyboard events, do you see a reason not to do that?

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, clicking without modifier collapses selection at the point. However, modifiers may change the behavior. For example, Shift expands selection from anchor node to clicked point. Looks like that the original patch tried to avoid conflict with the behavior.

Comment 11

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900)(Sick, maybe slow response) from comment #10)

Well, clicking without modifier collapses selection at the point. However, modifiers may change the behavior. For example, Shift expands selection from anchor node to clicked point. Looks like that [https://hg.mozilla.org/mozilla-central/rev/934ae18dd58f95b7023d6fda018c77deeb5a063d](the original patch) tried to avoid conflict with the behavior.

Masayuki: thanks, the text selection is an important point. One comment of the bug corresponding to the original patch also states that . Taking that into account, it seems reasonable to not fire change-events when a modifier key is pressed.

The issue of the reporter seems to be solvable with a <button> instead. Alex, can you confirm that? If so, I suggest closing this bug as invalid.

Comment 12

[alex.joseph.regan]

I didn't fix it with a button. Looking back at my application code, it looks like I had to put handlers on both the input and the label, as well as some kind of timestamp hack to prevent handling the same event twice. The input sets a timestamp, and the label checks it before handling its own event.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, it might be better to add bool attribute something like synthesized to MouseEvent, it should be true only when click event is fired only by clicking another element or Enter key press in form controls.