clicking on a <label> does not change the associated <input>

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: kaze, Unassigned)

Tracking

18 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
In this example:

  <label>
    <input type="checkbox" name="foo">
    <p> click me </p>
  </label>

clicking on the <label> element does not change the value of the checkbox. This is a rather recent regression.

Comment 1

6 years ago
If we can fix the touch target size, we could probably push this bug out.
blocking-basecamp: --- → ?
This is an annoying UI bug.

Does is only happen OOP?

Justin, ISTR you saying you had investigated here.  Can you do more of that or perhaps suggest someone else to own this?
Assignee: nobody → justin.lebar+bug
blocking-basecamp: ? → +
(In reply to Andrew Overholt [:overholt] from comment #2)
> Justin, ISTR you saying you had investigated here.  Can you do more of that
> or perhaps suggest someone else to own this?

I investigated this only to the point of comment 0.  That is, I observed it happening in the wifi settings screen.  :)
Assignee: justin.lebar+bug → nobody
(Reporter)

Comment 4

6 years ago
I confirm it’s not specific to OOP.
Is that specific to B2G/Gonk or mozbrowser?
Keywords: qawanted

Updated

6 years ago
QA Contact: jsmith
(In reply to Mounir Lamouri (:mounir) from comment #5)
> Is that specific to B2G/Gonk or mozbrowser?

General gecko actually. I can get this to reproduce this on desktop firefox nightly as well.
Keywords: qawanted
OS: Linux → All
QA Contact: jsmith
Hardware: x86_64 → All

Updated

6 years ago
Component: General → DOM
Product: Boot2Gecko → Core
Version: unspecified → 18 Branch

Updated

6 years ago
tracking-firefox18: --- → ?
This testcase works fine for me in FF desktop on my mac.

data:text/html,<label><input type="checkbox" name="foo"><p>click me</p></label>

What's the exact testcase that doesn't work for you on Desktop, Jason?
(In reply to Justin Lebar [:jlebar] from comment #7)
> This testcase works fine for me in FF desktop on my mac.
> 
> data:text/html,<label><input type="checkbox" name="foo"><p>click
> me</p></label>
> 
> What's the exact testcase that doesn't work for you on Desktop, Jason?

Same one. Digging into this, it depends on where you click on the label to see this bug repro or not on desktop. Let me get a video capturing this.
http://screencast.com/t/xDjxEeiux3

A way you could see this issue happen on desktop is to start clicking the label quickly repeatedly. Does that provide clarity?
(In reply to Jason Smith [:jsmith] from comment #9)
> http://screencast.com/t/xDjxEeiux3
> 
> A way you could see this issue happen on desktop is to start clicking the
> label quickly repeatedly. Does that provide clarity?

Tested in comparison also on FF OS. It's much harder to reproduce this bug on FF OS, and I wouldn't expect rapid clicks to happen there.
blocking-basecamp: + → ?
> A way you could see this issue happen on desktop is to start clicking the label quickly repeatedly. 

Isn't that just double-clicking, though?  I see that double-clicking is happening in the screenshot because the label text is getting highlighted.

If this issue is only apparent when you double-click on label text, I'm not sure that's a bug.

Now, it may be a bug if we allow double-clicks on B2G.  But that seems to be quite separate from what kaze was reporting in comment 0.
(In reply to Justin Lebar [:jlebar] from comment #11)
> > A way you could see this issue happen on desktop is to start clicking the label quickly repeatedly. 
> 
> Isn't that just double-clicking, though?  I see that double-clicking is
> happening in the screenshot because the label text is getting highlighted.
> 
> If this issue is only apparent when you double-click on label text, I'm not
> sure that's a bug.

Hmm okay. I was comparing behavior with Chrome, which didn't have this behavior I'm seeing on Firefox. I'll put a separate issue out on this, although I agree - not sure if this is a bug or not, depending on what the rules are here for what the expected behavior is (I can see an argument either way).

> 
> Now, it may be a bug if we allow double-clicks on B2G.  But that seems to be
> quite separate from what kaze was reporting in comment 0.

Yeah, the bug filed here I don't think I can reproduce then. So I'm closing this as a worksforme.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
tracking-firefox18: ? → ---
Resolution: --- → WORKSFORME
> So I'm closing this as a worksforme.

Waaait a second...Kaze, can you still reproduce this?  If so, can you give us a testcase?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> If so, can you give us a testcase?

I should say, a more-specific testcase, because the data: uri works fine.  :)
(Reporter)

Comment 15

6 years ago
OK, my bad. Before I go bury myself into a pile of crap, here’s a better test case.

This works:

  <label>
    <input type="checkbox" name="foo">
    <p> click me </p>
  </label>

This does not work: (= current bug in Gaia)

  <label for="foo">
    <input type="checkbox" name="foo">
    <p> click me </p> show password 
  </label>

This works:

  <label for="foo">
    <input type="checkbox" name="foo" id="foo">
    <p> click me </p> show password 
  </label>

Sorry for the noise here. I owe you all a beer for the time loss. :-s
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → INVALID
blocking-basecamp: ? → ---
You need to log in before you can comment on or make changes to this bug.