adoptNode() changes css class to lowercase for document loaded with XHR responseType = "document"

• Component: DOM
• Status: RESOLVED FIXED

[MarkG]

For a full demonstration, see https://jsfiddle.net/theblueslate/wxo7zst5/2/

I use XHR with responseType = "document" to load html fragments dynamically. To include them in the document, I use adoptNode(). However, if the XHR parsed document is from a document in quirks mode, and the contents contains a css class that includes an uppercase letter, then adoptNode() imports the element with the css class in lowercase.

importNode() doesn't have this problem, but is more heavyweight than adoptNode().

I can reproduce this problem on Safari 9.1.1 on El Capitan. I also have the same problem on iOS 9.3.2. This problem does not occur on Chrome 51 or IE11.

[Chris Dumez]

I have a fix that works for this test case but I need to do more validation.

[Radar WebKit Bug Importer]

<rdar://problem/27252541>

[Chris Dumez]

Created attachment 283203 [details]
Patch

[Chris Dumez]

Comment on attachment 283203 [details]
Patch

Breaks a W3C test.

[Build Bot]

Comment on attachment 283203 [details]
Patch

Attachment 283203 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1649107

New failing tests:
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html

[Build Bot]

Created attachment 283210 [details]
Archive of layout-test-results from ews114 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 283203 [details]
Patch

Attachment 283203 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1649136

New failing tests:
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html

[Build Bot]

Created attachment 283211 [details]
Archive of layout-test-results from ews103 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 283203 [details]
Patch

Attachment 283203 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1649137

New failing tests:
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html

[Build Bot]

Created attachment 283212 [details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Chris Dumez]

Created attachment 283214 [details]
Patch

[Chris Dumez]

Created attachment 283222 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 283222 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=283222&action=review

> LayoutTests/fast/dom/Document/adoptNode-quirks-mismatch.html:50
> +var xhr = new XMLHttpRequest();

Nit: indent this line.

> LayoutTests/fast/dom/Document/adoptNode-quirks-mismatch.html:53
> +    xhr.open("GET", tests[i], true);

Why don't we just do a sync XHR instead?  That'll make this test much easier to run and make it less racy.
This test won't be flaky because shouldBeEqualToString doesn't contain any document specific string
but we can't tell which case failed by just looking at the result because either document can be loaded first if async is set true.

Alternatively, you can trigger each XHR after the previous test had finished.
i.e. execute the next test in the else clause of documentLoaded.

[Chris Dumez]

Created attachment 283234 [details]
Patch

[MarkG]

@Ryosuke I believe XHR.responseType = "document" only works in async. See: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType

[Chris Dumez]

Created attachment 283236 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 283236 [details]
Patch

Clearing flags on attachment: 283236

Committed r203018: <http://trac.webkit.org/changeset/203018>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

The fix is incomplete.

[Chris Dumez]

Created attachment 283260 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 283260 [details]
Patch

Clearing flags on attachment: 283260

Committed r203043: <http://trac.webkit.org/changeset/203043>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.