Kenneth Reporter
	Description • 9 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.

	Gingerbread Man
	Comment 1 • 9 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

	Tooru Fujisawa [:arai] Assignee
	Comment 2 • 9 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?)

	Gingerbread Man
	Comment 3 • 9 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

	Tooru Fujisawa [:arai] Assignee
	Comment 4 • 9 years ago

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

	Tooru Fujisawa [:arai] Assignee
	Comment 5 • 9 years ago

changing summary to describe more specifically.

	Tooru Fujisawa [:arai] Assignee
	Comment 6 • 9 years ago

Filed spec bug
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28708

	Kenneth Reporter
	Comment 7 • 9 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 8 • 9 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.

	Tooru Fujisawa [:arai] Assignee
	Comment 9 • 9 years ago

Thank you for reviewing :D

the spec bug is filed here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28708

	Pulsebot
	Comment 10 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/3f1115f112af

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/3f1115f112af

	Tooru Fujisawa [:arai] Assignee
	Comment 12 • 9 years ago

Updated following document:
  https://developer.mozilla.org/en-US/Firefox/Releases/41
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

	Tooru Fujisawa [:arai] Assignee
	Comment 13 • 9 years ago

Spec bug is cloned to https://github.com/whatwg/html/issues/168

	Tooru Fujisawa [:arai] Assignee
	Comment 14 • 8 years ago

the spec is fixed now
https://github.com/whatwg/html/commit/528a22340a4bdc6ca0b0e190dfd239989123df9b
> Fix #168: <a> without href is not interactive content