Inconsistent and non-interoperable event targets for checkboxes covered with overlays and inside labels
Categories
(Core :: DOM: Events, defect)
Tracking
()
People
(Reporter: twisniewski, Unassigned)
References
()
Details
Attachments
(1 file)
522 bytes,
text/html
|
Details |
The checkboxes at Nokia's product pages do not work consistently in Firefox as compared to Chrome. The checkboxes consist of a label with a checkbox input, then a div.
Th issue appears to be because event targets are non-interoperable with the site's use of a CSS selector for highlighting the outline of their fake checkboxes on focus by adding a before pseudo:
<style>
input:focus + .placeholder::before {
content: ""; position: absolute; top: 0; left: 0; height: 2em; width:2em;
}
</style>
<label>
<input type="checkbox">
<div class="placeholder"></div>
</label>
If I disable that CSS selector, clicking on the checkboxes on their page seems to work consistently in Firefox (likewise if I add pointer-events:none
to the input).
I've made a test-case for this while I'm attaching to the bug. Clicking on the checkbox in the test-case gives very different results for the click events' targets, at least on my MacBook:
- Firefox alternates the target between the input and the div between clicks
- Chrome initially targets the input, then subsequent clicks always target the div
- Safari always targets the input
I'm not sure what's going on here, but it is affecting Nokia's product pages, and seems likely to affect other pages, since I see at least one page online suggesting to use this kind of technique for fake checkboxes.
Reporter | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
Gecko moves focus to document.body when clicking div, Blink doesn't move focus.
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 3•1 year ago
|
||
(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #2)
Gecko moves focus to document.body when clicking div, Blink doesn't move focus.
Masayuki, do you know how the behavior is specified? What is the reasonable behavior?
Comment 4•1 year ago
|
||
We move/clear focus as a default action of mousedown
:
https://searchfox.org/mozilla-central/rev/6f90f50b7a32cc062ab755e0653b3d3f512fe3bd/dom/events/EventStateManager.cpp#3449,3503-3504,3508,3546,3548,3552,3561,3578-3579,3590,3616,3626
I guess in the end of the loop, we should do something like:
if (auto* const labelElement = HTMLLabelElement::FromNode(newFocus)) {
nsGenericHTMLElement* control =
labelElement->GetLabelledElement();
if (control && control->OwnerDoc()->GetActiveElement() == control) {
newFocus = control;
break;
}
}
Then, we could avoid to move focus in the case, but I'm not sure this check is enough.
Comment 5•1 year ago
|
||
Verified this issue and could not reproduce it on Firefox Nightly following the test case provided. Also, the page does not present any checkboxes anymore, as I have tried multiple products. Tom, is this still an issue?
Tested with:
Browser / Version: Firefox Nightly 128.0a1 (2024-05-29) (64-bit)
Operating System: Windows 10 PRO x64
Reporter | ||
Comment 6•1 year ago
|
||
Yes, there is still an interop issue here. Chrome, Firefox and Safari fire different events when I click the checkbox in the testcase quickly on my Macbook.
However, if Nokia's page isn't reproducing the problem anymore, then we can drop the webcompat priority for now until we discover other actual website breakage.
Description
•