Open Bug 1037941 Opened 7 years ago Updated 6 years ago

Selection of text in <label> interferes with focusing the labeled control

Categories

(Core :: DOM: Events, defect)

30 Branch
defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: xracoonx, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

example-html: <label><input type="checkbox">Testlabel</label>

1. Press and hold the mouse button on the label. 
2. While holding the button pressed move the mouse pointer around and move it back on the label. 
3. Release the button.


Actual results:

The element associated with the label does not get selected/checked.


Expected results:

The element associated with the label does get selected/checked.

In the example above that this is the correct behavior is also indicated by the checkbox being grayed before the button is released. 
This is basically the normal behavior of <input type="submit"> as well.
Note that the way Chrome does this, it's impossible to select text in the label (that isn't at either end of the label).

Not sure what's preferred in this case. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#activation seems to indicate this depends on the behaviour of 'click' events, which dom 3 events specs as:

"Each implementation will determine the appropriate hysteresis tolerance, but in general SHOULD fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and SHOULD fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different."

Clearly, the "no mouseout or mouseleave events intervening" thing is not true in the steps listed in comment #0 - but in fact, even if you only drag the mouse across the text without leaving the element, we don't fire a click event.

Olli, can you correct/clarify my amateur spec reading here? :-)
Component: Untriaged → DOM: Events
Flags: needinfo?(bugs)
Keywords: testcase
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Summary: Moving mouse pointer does not work with <label> → Selection of text in <label> interferes with focusing the labeled control
No correction there.
Selection handling as such isn't AFAIK really specified anywhere, and our current behavior makes
sense to me.
Flags: needinfo?(bugs)
Well, I think that selecting text is less important on labels (of e.g. checkboxes), than being able to select it with no problem. I found myself several times clicking on a label without the desired result just because my ThinkPad track-point did some more moving. Maybe that is a technical problem of trackpoints, but maybe there are more devices that face that problem.

Anyway, if the behavior as it is is indeed the desired one, then this should be at least indicated by not making the checkbox look grayed anymore as if a release of the mouse button would trigger a selection.
Duplicate of this bug: 1045021
This bug is a regression: it was introduced by the fix of "Bug 382369 - Cannot select text in <label> associated with a <select>" in file "HTMLLabelElement.cpp".

This bug has a big impact for touchscreens: it's frequent that mouse moves slightly while clicking.

In my opinion, selecting text inside a label is an unwanted feature or at least it's incoherent with anchors and other clickable elements for which that feature doesn't exist.
However, we can make both features to coexist by increasing the "CLICK_DISTANCE" constant in HTMLLabelElement.cpp. It's currently hardcoded to 2. I changed it to 20 and tested: it's still possible to select text, and it's less tricky to click the label with a touchscreen.
Maybe we should put it in a config parameter instead of a hardcoded constant too.
Hi there,

This bug was opened a few month ago. It is definitely a regression (I've linked the bug ticket that indroduced this wrong behaviour).

Can somebody with powers change the status of this bug so it can be looked at by the developers?

I've given a possible solution (I actually tested it) that would fix it without any drawback. It's just a hardcoded constant to change (CLICK_DISTANCE to 20 instead of 2 in HTMLLabelElement.cpp).

Thanks,
(In reply to Olivier Godart from comment #6)
> Hi there,
> 
> This bug was opened a few month ago. It is definitely a regression (I've
> linked the bug ticket that indroduced this wrong behaviour).
> 
> Can somebody with powers change the status of this bug so it can be looked
> at by the developers?

It can already be looked at by developers. This is a public bug database, and apart from some edge cases like security-sensitive bugs, all of the bugs are public and accessible to anyone.

Rather than think of it as "powers" vs. "people without powers", please understand that more bugs are being filed than can be fixed, and (generally speaking) bugs get fixed when their importance/severity/impact puts them high enough on the list of things that developers work on.

> I've given a possible solution (I actually tested it) that would fix it
> without any drawback. It's just a hardcoded constant to change
> (CLICK_DISTANCE to 20 instead of 2 in HTMLLabelElement.cpp).

This is good to know, thank you! Olli, would we take a patch to make this a hidden pref, and/or do you think we can do better here?
Flags: needinfo?(bugs)
No hidden prefs, please. But I wonder if we could use the same values as 
http://mxr.mozilla.org/mozilla-central/source/dom/events/EventStateManager.cpp?rev=ee9403c598d6#1588

Olivier, want to test that approach?
Flags: needinfo?(bugs)
Hi Olli,

I tested this approach and it seems perfect.
I'm attaching a patch so you can review it.

Best regards,
Olivier
Attachment #8531194 - Flags: review?(bugs)
Comment on attachment 8531194 [details] [diff] [review]
Patch to fix  Bug 1037941

So could you add a static helper method to EventStateManager and get the values from there.

(Sorry about the delay with the review. Promise to do the next one faster.)
Attachment #8531194 - Flags: review?(bugs) → review-
For the time being I use a workaround. I attach to every label the following javascript event:

onmousedown="document.getElementById(this.getAttribute('for')).click();"

It is not perfect but works for me.
You need to log in before you can comment on or make changes to this bug.