1613075 - Checkbox and radio button toggles when partially select label by mouse

Status: NEW

(Toolkit :: UI Widgets, defect, P3)

Description

[Alice0775 White]

This is very annoying. The problem happens on about:preferences.
However, this problem does not happen on ordinarily web page.

Steps to reproduce:

1. Open about:preferences
2. Try select partial text of checkbox/radio button label by mouse

Actual results:
checkbox/radio button toggles unexpectedly.

Expected results:
should not toggle

Comment 1

[:Gijs (he/him)]

Hm, I guess we avoid doing this for clicks on web content but not in our formerly-XBL-now-custom-element bindings?

The "straightforward" solution for the prefs would be to switch to HTML labels in the prefs, but given the number of labels that's a pretty regression-prone change...

Brian, do you know what our long-term plans here are and if it's worth fixing this in the XUL-ish versions of <label> ?

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to :Gijs (he/him) from comment #1)

Hm, I guess we avoid doing this for clicks on web content but not in our formerly-XBL-now-custom-element bindings?

The "straightforward" solution for the prefs would be to switch to HTML labels in the prefs, but given the number of labels that's a pretty regression-prone change...

Brian, do you know what our long-term plans here are and if it's worth fixing this in the XUL-ish versions of <label> ?

I'd like to ultimately migrate them to html:label (at least the ones that don't use [value]) - landing a replacement widget is filed as Bug 1602095. There's even have a prototype that converts the existing Custom Element to work in content (minus pref access to handle various access key prefs). I've cc'ed :mstriemer here, since he has an interest in using that widget in about:addons and possibly other in-content pages, some of which aren't chrome priv. Pushing this forward for about:preferences could maybe fit in with the in-content widget unification efforts (though I don't want to speak for him about any overlap here).

Though as you say doing so is regression prone. We might be able to mitigate that by using <html:label> with display: -moz-box, and stop using [flex=N] (Bug 1593303). We could first land a .flex-1 class and then migrate a subset of labels to use that class first (like those in prefs), if we don't want to be blocked on all of Bug 1593303.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:bgrins, could you have a look please?

For more information, please visit auto_nag documentation.