New issue
Advanced search Search tips

Issue 685012 link

Starred by 2 users

Issue metadata

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

Blocked on:
issue 627682



Sign in to add a comment

document.createElement should use ASCII lowercasing, not Unicode lowercasing

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

Issue description

Chrome Version: 58.0.2991.0
OS: macOS 10.12.2

What steps will reproduce the problem?
(1) Open http://w3c-test.org/dom/nodes/Document-createElement.html in Chrome.
(2) Observe the test results.

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

What happens instead?
The following two tests fail:
Fail	createElement("marK") in HTML document
	assert_equals: localName expected "marK" but got "mark"
Fail	createElement("İnput") in HTML document
	assert_equals: localName expected "İnput" but got "i̇nput"

Further details:

Per https://dom.spec.whatwg.org/#dom-document-createelement
> 2. If the context object is an HTML document, then set localName to localName in ASCII lowercase.

The test results indicate that Chrome is applying Unicode-sensitive lowercasing to the localName argument,
instead of ASCII-only lowercasing as required by the spec.
 

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

Blocking: 627682
Components: Blink>DOM
Labels: Hotlist-Interop Hotlist-GoodFirstBug
Status: Available (was: Untriaged)

Comment 2 by tkent@chromium.org, Jan 25 2017

Blockedon: 627682
Blocking: -627682

Comment 3 by tval...@gmail.com, Jan 27 2017

Hello,
as I can see in:
AtomicString Document::convertLocalName(const AtomicString& name) {
  return isHTMLDocument() ? name.lower() : name;
}

we can change to:
AtomicString Document::convertLocalName(const AtomicString& name) {
  return isHTMLDocument() ? name.lowerASCII() : name;
}
And tests will be ok (also it fix some fails in Document-createAttribute.html tests).

But after this fix we have another problem:
Fail	createElement("ınput") in HTML document	assert_equals: tagName expected "ıNPUT" but got "INPUT"

What do you think about it?
I guess the first thing to work out is: What does the spec say to do? Is the test correct? And, what do other browsers do?

Comment 5 by phistuck@gmail.com, Feb 3 2017

Using BrowserStack -
Safari 10 - everything passes.
Edge 14 - fails all of the İnput and marK tests (9 tests) due to an InvalidCharacterError. It also fails ெfoo tests and some more tests (15 tests) due to not throwing.
Internet Explorer 11 - same as Edge 14. Funny - Internet Explorer 6 did not throw that error. :)
Firefox 50 - everything passes.
Chrome - 3 failures -
createElement("marK") in HTML document - localName expected "marK" but got "mark"
createElement("İnput") in HTML document - localName expected "İnput" but got "i̇nput"
createElement("ınput") in HTML document - tagName expected "ıNPUT" but got "INPUT"
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 1 2017

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

commit 1337a0b763dc552f6eeadb17df348429b34a3501
Author: ratsunny <ratsunny@gmail.com>
Date: Wed Mar 01 22:08:41 2017

Use the correct case converter for |localName| and |tagName|

Per spec[1], document.createElement should set |localName|
to ASCII lowercase when context object is an HTML document.

Now the AtomicString::lower() was used,
but it converts characters more than ASCII into lowercase.
So we should use AtomicString::lowerASCII() instead.

Besides, per spec[2], Element.tagName should be set to ASCII
uppercase when context object is in HTML namespace and its node
document is an HTML document.

Now we are using (Atomic)String::upper() due to lack of
ASCII uppercase support. So (Atomic)String::upperASCII() is
added to solve this issue, and AtomicString::upper() is removed
since it's not used anymore.

Tests were changed accordingly

[1]: https://dom.spec.whatwg.org/#dom-document-createelement
[2]: https://dom.spec.whatwg.org/#dom-element-tagname

BUG= 685012 

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

[delete] https://crrev.com/494a3b618ecf62e96f14c195a0d2234b20db785c/third_party/WebKit/LayoutTests/external/wpt/dom/nodes/Document-createElement-expected.txt
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/LayoutTests/external/wpt/dom/nodes/Document-getElementsByTagName-expected.txt
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/LayoutTests/external/wpt/dom/nodes/Element-getElementsByTagName-expected.txt
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/LayoutTests/external/wpt/dom/nodes/case-expected.txt
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/core/dom/QualifiedName.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/core/html/HTMLElement.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/AtomicString.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/AtomicString.h
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/StringImpl.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/StringImpl.h
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/StringImplTest.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/WTFString.cpp
[modify] https://crrev.com/1337a0b763dc552f6eeadb17df348429b34a3501/third_party/WebKit/Source/wtf/text/WTFString.h

Comment 7 by tkent@chromium.org, Mar 1 2017

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

Sign in to add a comment