Document created by DOMParser.parseFromString() doesn't have correct MIME type |
||
Issue descriptionChrome Version: 59 canary OS: All but iOS What steps will reproduce the problem? (1) Open http://w3c-test.org/dom/nodes/Document-createElement-namespace.html What is the expected result? No FAILs What happens instead? There are four FAILs. Please use labels and text to provide additional information. https://w3c.github.io/DOM-Parsing/#dom-domparser-parsefromstring > In any case, the returned Document's content type must be the type argument. DOMParser::parseFromString() should call |doc->setMimeType(type)|.
,
Mar 13 2017
Currently making a patch for this.
,
Mar 13 2017
,
Mar 13 2017
(Sorry Loorong..., saw your message afterwards)
,
Mar 13 2017
No worries, closed mine just now.
,
Mar 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/991d1fb3865a730afd1d1891ace471cb59432d8b commit 991d1fb3865a730afd1d1891ace471cb59432d8b Author: martin <martin@martinrogalla.com> Date: Mon Mar 13 05:30:05 2017 Use parseFromString type arg to set mime type. This patch ensures that the type argument for parseFromString(str, type) [1] is used to set the MIME type of the resulting document. It makes all DOMParser tests in [2] pass. [1] - https://w3c.github.io/DOM-Parsing/#dom-domparser-parsefromstring [2] - http://w3c-test.org/dom/nodes/Document-createElement-namespace.html BUG= 700237 Review-Url: https://codereview.chromium.org/2744153002 Cr-Commit-Position: refs/heads/master@{#456325} [modify] https://crrev.com/991d1fb3865a730afd1d1891ace471cb59432d8b/third_party/WebKit/LayoutTests/external/wpt/dom/nodes/Document-createElement-namespace-expected.txt [modify] https://crrev.com/991d1fb3865a730afd1d1891ace471cb59432d8b/third_party/WebKit/LayoutTests/external/wpt/domparsing/DOMParser-parseFromString-xml-expected.txt [modify] https://crrev.com/991d1fb3865a730afd1d1891ace471cb59432d8b/third_party/WebKit/Source/core/xml/DOMParser.cpp
,
Mar 13 2017
I found our imported Document-createElement-namespace.html still had FAILs after #6 because we didn't import some sub-resource files.
,
Mar 14 2017
The tests that are failing due to the fact that the document.contentType of the source test files are determined in Chromium as "application/xhtml+xml", while in Firefox their document.contentType is determined to be "application/xml". http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml.xml http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_removed.xml http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_changed.xml I do not exactly know what the standards are, but since the xml files contain xhtml, it would make sense to me that their content-type is "application/xhtml+xml".
,
Mar 14 2017
*To be clear: the test asserts that the document.contentType is "application/xml" and hence fails.
,
Mar 14 2017
yeah, remaining failures are not related to DOMParser.parseFromString(). > http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml.xml The header sent from the server contains: Content-Type: application/xml Though the specification doesn't mention contentType processing for XML documents [1], setting Content-Type HTTP header value looks very straight-forward behavior. We should check other browser's behavior. [1] https://html.spec.whatwg.org/multipage/browsers.html#read-xml
,
Mar 14 2017
After some searching I found that the mime type is changed from "application/xml" to " application/xhtml+xml" in https://cs.chromium.org/chromium/src/content/browser/loader/mime_sniffing_resource_handler.cc?l=280 Safari and Firefox both use "application/xml" for these documents.
,
Mar 16 2017
Filed Issue 702084 for the application/xhtml+xml issue. |
||
►
Sign in to add a comment |
||
Comment 1 by tkent@chromium.org
, Mar 10 2017