Clicking on CSS selects automatically selects all text of the label
Categories
(Core :: DOM: Selection, defect)
Tracking
()
People
(Reporter: support, Assigned: masayuki)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
switch_selection.gif
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
Consider this HTML and CSS.
HTML:
<html>
<head>
</head>
<body>
<span>Toggle Switch </span>
<input type="checkbox" id="toggle" />
<label for="toggle"></label>
</body>
</html>
CSS:
#toggle {
display: none;
}
label {
display: inline-block;;
width: 40px;
height: 20px;
background-color: #ccc;
border-radius: 10px;
position: relative;
cursor: pointer;
margin-left: 32px;
}
label::before {
content: "";
position: absolute;
top: 2px;
left: 2px;
width: 16px;
height: 16px;
background-color: white;
border-radius: 50%;
transition: transform 0.3s;
}
#toggle:checked + label {
background-color: #2196F3;
}
#toggle:checked + label::before {
transform: translateX(20px);
}
Actual results:
When enabling or disabling the switch multiple times, the browser automatically selects the label text. See attached GIF for an example.
Expected results:
The text should not be selected when the user interacts with the switch.
This does not happen in either Chrome, Edge or Safari
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
It looks like what's happening is that if you click the toggle three times in quick succession, this is handled as a triple-click event that selects the entire line. Given that the control is responding to the individual clicks, I guess they probably shouldn't be also getting bubbled up to work as a selection event. Maybe more of an Events issue than Layout?
FWIW, I see a similar thing in Chrome, not with triple-clicking but if I double-click the toggle, the space before it gets selected (because double-click is a word-select action). If I remove all the intervening spaces between the label text and the control, then double-clicking the control selects the whole word "Switch".
For me, both double- and triple-click selection behaviors do reproduce in Safari, too.
Could you also check if it behaves for you on these switches?
https://demos.blazorbootstrap.com/form/switch
|
|
||
Comment 4•2 years ago
|
||
(In reply to support from comment #3)
Could you also check if it behaves for you on these switches?
https://demos.blazorbootstrap.com/form/switch
With these, I'm seeing double-clicking the switch in Firefox selects the first word of the label ("Default" or "Checked"), but I haven't been able to reproduce the triple-click selecting the whole line.
In Safari and Chrome, I haven't seen the "spurious" selection behavior with these.
(I also noticed that in all three browsers, clicking on the text of the label will both select text and toggle the switch, which also seems unexpected from a user's point of view.)
|
||
Comment 5•2 years ago
|
||
Yeah I see that too, I guess our selection code is just buggy.
I'll take a look this one
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 6•2 years ago
|
||
|
|
||
Comment 7•2 years ago
|
||
|
|
||
Comment 8•2 years ago
|
||
Emilio, do you mind take a look?
|
||
Comment 9•2 years ago
|
||
So this is only a regression in the sense that it made triple-click actually span the whole line. So that's working as intended.
However there's the issue of "why are we selecting the whole line when clicking on that label and not e.g., on a checkbox?". That's also easy to answer and is because nsCheckboxRadioFrame::HandleEvent early-returns.
I'm having a hard time figuring out what makes this test-case special in other browsers, and I ran out of time today to investigate this a bit more. The Chrome code is here fwiw.
Masayuki, have you investigated interop of this area by any chance?
|
|
||
Comment 10•2 years ago
|
||
As a workaround, user-select: none; on the label would do, fwiw.
|
Assignee | |
Comment 11•2 years ago
|
||
No. However, I think that if the click target is a <label> and the click changed the state of the target like a checkbox or a radio, the click should be consumed and should not cause another default action like select word/paragraph.
|
|
Assignee | |
Comment 12•2 years ago
|
||
Extending selection for a double\triple click is handled in
nsIFrame::HandleEvent but HTMLLabelElement::PostHandleEvent is called
after that. So unfortunately, nsIFrame cannot know the result of
HTMLLabelElement. Therefore, this patch adds a special path for <label>
in nsIFrame::HandleMultiplePress which is a helper method of
nsIFrame::HandleEvent.
It might be better to stop handling it only when the labeled element is
<input type="checkbox"> or <input type="radio"> because they are the
only types their value is changed only by a click and the label may be
clicked multiple times.
|
||
Updated•2 years ago
|
|
|
||
Comment 13•2 years ago
|
||
Set release status flags based on info from the regressing bug 1603964
|
||
Updated•2 years ago
|
|
|
||
Comment 14•2 years ago
|
||
I think this is potentially invalid, see the bug there and extra test-case.
|
||
Updated•2 years ago
|
|
|
||
Comment 15•1 year ago
|
||
Chrome behaves like us in the reduced test-case now.
|
|
||
Updated•1 year ago
|
Description
•