New issue
Advanced search Search tips

Issue 683461 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

HTMLLabelElement.control should return null when its `for` attribute refers to an element in a different tree

Project Member Reported by cvrebert@google.com, Jan 21 2017

Issue description

Chrome Version: 55.0.2883.95
OS: macOS 10.12.2

What steps will reproduce the problem?
(1) Open http://w3c-test.org/html/semantics/forms/the-label-element/label-attributes.html in Chrome.
(2) Observe the test results.

What is the expected result?
All the tests on the page should pass.

What happens instead?
One of the tests fails:
Fail
A label element not in a document can not label any element in the document.	
assert_not_equals: A label element not in a document should not label an element in a document. got disallowed value Element node <input id="test1"></input>

Further details:
The test in question basically does:
    var label = document.createElement("label");
    label.htmlFor = "idOfAnInputInTheDocument";
    assertEqual(label.control, null);
And the assertion fails because `.control` returns the corresponding <input> instead of null.

Per https://html.spec.whatwg.org/multipage/#dom-label-control
> The `control` IDL attribute must return the label element's **labeled control**, if any,
> or null if there isn't one.

Per https://html.spec.whatwg.org/multipage/#attr-label-for
> If the [`for`] attribute is specified, the attribute's value must be
> the ID of a labelable element in the same **tree** as the label element.
> If the [`for`] attribute is specified
> and there is an element in the **tree** whose ID is equal to the value of the `for` attribute,
> and the first such element in tree order is a labelable element,
> then that element is the label element's **labeled control**.

And **tree** is defined by https://dom.spec.whatwg.org/#concept-tree
Since `label.parentNode === null` in our case,
my reading is that the <label> and the <input> are in different trees.

Therefore, the <label> has no **labeled control** and HTMLLabelElement.control should return null.
 

Comment 1 by tkent@chromium.org, Jan 22 2017

Labels: Hotlist-Interop Hotlist-GoodFirstBug
Status: Available (was: Untriaged)
HTMLLabelElement::control doesn't check if the labelable element and the label are in the same tree.

I believe it would be enough to add:

if(!isInTreeScope()) return nullptr; 

before we check if the element is labelable.

Comment 3 by tkent@chromium.org, Feb 9 2017

> if(!isInTreeScope()) return nullptr; 

Right. We should add it before getElementById(controlId) in HTMLLabelElement::control().

Project Member

Comment 4 by bugdroid1@chromium.org, Feb 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b0d6dc9fc0c9ad8b4944fa48125ad5bcf3f29146

commit b0d6dc9fc0c9ad8b4944fa48125ad5bcf3f29146
Author: Matthieu.Rigolot <Matthieu.Rigolot@gmail.com>
Date: Sat Feb 11 11:55:32 2017

Modify HTMLLabelElement::control to check if label is in tree scope

HTMLLabelElement.control should not return the input element if <label> and <input> are in different trees.

New behavior matches to the specification as per:
https://html.spec.whatwg.org/#labeled-control

BUG= 683461 

Review-Url: https://codereview.chromium.org/2692473003
Cr-Commit-Position: refs/heads/master@{#449855}

[delete] https://crrev.com/d2a4caef5b812732dce7baa2d56716f8ae1f8cd2/third_party/WebKit/LayoutTests/external/wpt/html/semantics/forms/the-label-element/label-attributes-expected.txt
[modify] https://crrev.com/b0d6dc9fc0c9ad8b4944fa48125ad5bcf3f29146/third_party/WebKit/Source/core/html/HTMLLabelElement.cpp

Comment 5 by tkent@chromium.org, Feb 12 2017

Labels: M-58
Status: Fixed (was: Available)

Sign in to add a comment