This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27684 - Handling of .contentType is not interoperable
Summary: Handling of .contentType is not interoperable
Status: RESOLVED DUPLICATE of bug 22960
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-22 15:31 UTC by Robin Berjon
Modified: 2014-12-23 12:51 UTC (History)
2 users (show)

See Also:


Attachments

Description Robin Berjon 2014-12-22 15:31:12 UTC
We're observing pretty varying behaviour for .contentType, looking at this test:

    http://w3c-test.org/dom/nodes/Document-createElement-namespace.html

Parts of the failures are for synthetic documents. For those, both WebKit and Blink use the content type that would "ideally" match the namespace given to createDocument() instead of "application/xml". I somehow suspect that the issue (at least in the way in which it is implemented) is related to bug 19431.

Other failures, notably in Blink, apply to remotely-loaded documents, notably involving attempts to change the content type by swapping the root element while loading:

    Vanilla load XHTML as application/xml: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml.xml
    Try changing to SVG: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_changed.xml
    Try changing to without namespace: http://w3c-test.org/dom/nodes/Document-createElement-namespace-tests/xhtml_ns_removed.xml


The externally-loaded ones likely ought to be handled by other specifications that build DOMs (in this case HTML), but I am including them in case the additional data helps.

The synthetic cases however ought to be defined by the DOM, and we're lacking interoperability today. Gecko sticks to the spec (Unless stated otherwise, a document's (...) content type is "application/xml") but it would seem that no one else does. It is worth tracking whether this is something that implementers wish to align on or not.
Comment 1 Anne 2014-12-23 08:54:30 UTC
Sounds like bug 22960. Did you file bugs on browsers for violating the specification?
Comment 2 Robin Berjon 2014-12-23 12:51:11 UTC
(In reply to Anne from comment #1)
> Sounds like bug 22960. Did you file bugs on browsers for violating the
> specification?

Yes indeed, it stems from the same root. No need to file since it in effect already is :)

*** This bug has been marked as a duplicate of bug 22960 ***