RESOLVED FIXED 159555
adoptNode() changes css class to lowercase for document loaded with XHR responseType = "document"
https://bugs.webkit.org/show_bug.cgi?id=159555
Summary adoptNode() changes css class to lowercase for document loaded with XHR respo...
MarkG
Reported 2016-07-08 05:17:46 PDT
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.
Attachments
Patch (7.01 KB, patch)
2016-07-08 15:28 PDT, Chris Dumez
no flags
Archive of layout-test-results from ews114 for mac-yosemite (1.45 MB, application/zip)
2016-07-08 16:22 PDT, Build Bot
no flags
Archive of layout-test-results from ews103 for mac-yosemite (874.58 KB, application/zip)
2016-07-08 16:23 PDT, Build Bot
no flags
Archive of layout-test-results from ews104 for mac-yosemite-wk2 (773.02 KB, application/zip)
2016-07-08 16:26 PDT, Build Bot
no flags
Patch (6.98 KB, patch)
2016-07-08 16:28 PDT, Chris Dumez
no flags
Patch (6.96 KB, patch)
2016-07-08 16:44 PDT, Chris Dumez
no flags
Patch (6.85 KB, patch)
2016-07-08 18:23 PDT, Chris Dumez
no flags
Patch (7.04 KB, patch)
2016-07-08 18:36 PDT, Chris Dumez
no flags
Patch (6.12 KB, patch)
2016-07-09 08:14 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2016-07-08 13:40:01 PDT
I have a fix that works for this test case but I need to do more validation.
Radar WebKit Bug Importer
Comment 2 2016-07-08 13:40:19 PDT
Chris Dumez
Comment 3 2016-07-08 15:28:51 PDT
Chris Dumez
Comment 4 2016-07-08 16:07:03 PDT
Comment on attachment 283203 [details] Patch Breaks a W3C test.
Build Bot
Comment 5 2016-07-08 16:22:36 PDT
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
Comment 6 2016-07-08 16:22:40 PDT
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 7 2016-07-08 16:23:22 PDT
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
Comment 8 2016-07-08 16:23:27 PDT
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 9 2016-07-08 16:26:28 PDT
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
Comment 10 2016-07-08 16:26:33 PDT
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
Comment 11 2016-07-08 16:28:07 PDT
Chris Dumez
Comment 12 2016-07-08 16:44:52 PDT
Ryosuke Niwa
Comment 13 2016-07-08 17:08:11 PDT
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
Comment 14 2016-07-08 18:23:28 PDT
MarkG
Comment 15 2016-07-08 18:27:35 PDT
@Ryosuke I believe XHR.responseType = "document" only works in async. See: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType
Chris Dumez
Comment 16 2016-07-08 18:36:46 PDT
WebKit Commit Bot
Comment 17 2016-07-08 19:25:11 PDT
Comment on attachment 283236 [details] Patch Clearing flags on attachment: 283236 Committed r203018: <http://trac.webkit.org/changeset/203018>
WebKit Commit Bot
Comment 18 2016-07-08 19:25:19 PDT
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 19 2016-07-09 08:10:11 PDT
The fix is incomplete.
Chris Dumez
Comment 20 2016-07-09 08:14:43 PDT
WebKit Commit Bot
Comment 21 2016-07-10 16:28:49 PDT
Comment on attachment 283260 [details] Patch Clearing flags on attachment: 283260 Committed r203043: <http://trac.webkit.org/changeset/203043>
WebKit Commit Bot
Comment 22 2016-07-10 16:28:55 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.