Anchor element without href attribute inside label does not activate associated form element

RESOLVED FIXED in Firefox 41

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: Kenneth, Assigned: arai)

Tracking

({regression})

38 Branch
mozilla41
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox41 fixed)

Details

(Whiteboard: [parity-chrome][parity-opera], URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36

Steps to reproduce:

An anchor element inside a label element will not activate the associated form element when clicked.

<label for="a">
<a>Click Here</a>
</label>
<input id="a" type="checkbox">


Actual results:

When clicking "Click Here", the checkbox quickly toggles the checked attribute and restores it to what it was before clicking.


Expected results:

When clicking "Click Here", the checkbox should toggle its checked attribute.

This works as expected in branch 37 and earlier.  I also tried the developer edition 40.0a2, to no avail.

Comment 1

3 years ago
regressionwindow
Last good: 2015-01-20 | https://hg.mozilla.org/mozilla-central/rev/93f526d85b47
First bad: 2015-01-21 | https://hg.mozilla.org/mozilla-central/rev/540077a30866

Push log
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=93f526d85b47&tochange=540077a30866
Blocks: 229925
Component: Untriaged → Layout: Form Controls
Keywords: regression
Product: Firefox → Core
Whiteboard: [parity-chrome][parity-opera]
(Assignee)

Comment 2

3 years ago
Actually, this was an intended change, to make it conform to the spec.

https://html.spec.whatwg.org/multipage/forms.html#the-label-element:the-label-element-10
> The activation behaviour of a label element for events targeted at interactive
> content descendants of a label element, and any descendants of those
> interactive content descendants, must be to do nothing.

https://html.spec.whatwg.org/multipage/dom.html#interactive-content-2
> Interactive content is content that is specifically intended for user
> interaction.
>  => a, audio (if the controls attribute is present), button, details, ...

so, this could be a spec issue. I guess adding a restriction "if the href attribute is present" to "a" element might solve it.

Kenneth, is this a regression happening on actual web page? If so, do you think above change will solve it? (I mean, does the element have no "href" attribute?)

Similar issue about an element with tabindex, which caused web compatibility issue, was filed as bug 1141455 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28212

(In reply to Kenneth from comment #0)
> Actual results:
> 
> When clicking "Click Here", the checkbox quickly toggles the checked
> attribute and restores it to what it was before clicking.

It doesn't toggle the checked attribute at all, the checkbox changes it's visual because of :hover and :active selector. This time the behavior will be fixed in other way, but might be better to file a bug about this too.

https://html.spec.whatwg.org/multipage/scripting.html#selector-hover
> The :hover pseudo-class is defined to match an element "while the user
> designates an element with a pointing device". For the purposes of defining
> the :hover pseudo-class only, an HTML user agent must consider an element as
> being one that the user designates if it is:
>  * An element that the user indicates using a pointing device.
>  * An element that has a descendant that the user indicates using a pointing device.
>  * An element that is the labeled control of a label element that is currently matching :hover.
> [Example]
> Consider in particular a fragment such as:
>   <p> <label for=c> <input id=a> </label> <span id=b> <input id=c> </span> </p>
> If the user designates the element with ID "a" with their pointing device,
> ...
> and the element with ID "c" matches it through condition 3 (its label element
> matches :hover).

https://html.spec.whatwg.org/multipage/scripting.html#selector-active
> The :active pseudo-class is defined to match an element "while an element is
> being activated by the user".
> To determine whether a particular element is being activated for the purposes
> of defining the :active pseudo-class only, an HTML user agent must use the
> first relevant entry in the following list.
>   If the element has a descendant that is currently matching the :active
>   pseudo-class
>     The element is being activated.
>   If the element is the labeled control of a label element that is currently
>   matching :active
>     The element is being activated.
>   ...
>   If the element is being actively pointed at
>     The element is being activated.

The :hover's example is almost same situation as the HTML in comment #0. The difference is that the label's activation behavior is "do nothing" for this case, but the hover conditions don't reflect the activation behavior, according to the spec (am I correct?)
Flags: needinfo?(kenneth.gendron)

Comment 3

3 years ago
(In reply to Tooru Fujisawa [:arai] from comment #2)
> It doesn't toggle the checked attribute at all, the checkbox changes it's
> visual because of :hover and :active selector. This time the behavior will
> be fixed in other way, but might be better to file a bug about this too.

Bug 1167862
OS: Unspecified → All
Hardware: Unspecified → All
(Assignee)

Updated

3 years ago
See Also: → bug 1167862
(Assignee)

Comment 4

3 years ago
Created attachment 8611526 [details] [diff] [review]
Do not treat anchor element without href attribute an interactive content.

Just made HTMLAnchorElement::IsInteractiveHTMLContent return false if it doesn't have href attribute.
Do we need to add bool argument `bool aIgnoreAnchorWithoutHref` like `bool aIgnoreTabindex` this time too? (or... do we still need latter one?)

Green on try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3a229badff21
Assignee: nobody → arai.unmht
Attachment #8611526 - Flags: review?(bugs)
(Assignee)

Comment 5

3 years ago
changing summary to describe more specifically.
Summary: Anchor element inside label does not activate associated form element → Anchor element without href attribute inside label does not activate associated form element
(Reporter)

Comment 7

3 years ago
(In reply to Tooru Fujisawa [:arai] from comment #2)
> Kenneth, is this a regression happening on actual web page? If so, do you
> think above change will solve it? (I mean, does the element have no "href"
> attribute?)

I believe it will.  I purposely removed the HREF attribute.
Flags: needinfo?(kenneth.gendron)

Comment 8

3 years ago
Comment on attachment 8611526 [details] [diff] [review]
Do not treat anchor element without href attribute an interactive content.

ah, this is what blink does at least. Somewhat odd behavior but fine.
Please file a spec bug.
Attachment #8611526 - Flags: review?(bugs) → review+
(Assignee)

Comment 9

3 years ago
Thank you for reviewing :D

the spec bug is filed here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28708
https://hg.mozilla.org/mozilla-central/rev/3f1115f112af
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
(Assignee)

Comment 13

3 years ago
Spec bug is cloned to https://github.com/whatwg/html/issues/168
(Assignee)

Comment 14

2 years ago
the spec is fixed now
https://github.com/whatwg/html/commit/528a22340a4bdc6ca0b0e190dfd239989123df9b
> Fix #168: <a> without href is not interactive content
You need to log in before you can comment on or make changes to this bug.