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

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> ?

(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.

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

For more information, please visit auto_nag documentation.