HTMLLabelElement.control should return null when its `for` attribute refers to an element in a different tree |
||
Issue descriptionChrome 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.
,
Feb 9 2017
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.
,
Feb 9 2017
> if(!isInTreeScope()) return nullptr; Right. We should add it before getElementById(controlId) in HTMLLabelElement::control().
,
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
,
Feb 12 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by tkent@chromium.org
, Jan 22 2017Status: Available (was: Untriaged)