Summary: | When assigning to innerHTML of an element in an XHTML document, HTML entities are not recognized | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jim Driscoll <maus> | ||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED WONTFIX | ||||||
Severity: | Major | CC: | abarth, ap, cdumez, ian, janderssn, mrowe | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Jim Driscoll
2009-10-29 13:16:35 PDT
Can you please provide a complete test case that demonstrates the problem? In my quick test the JavaScript snippet behaved as I expect. The document must be served with the application/xml+xhtml content type for this error to occur. 1. open http://www.w3c.org (they serve their pages with the application/xml+xhtml content-type) 2. in the web inspector type document.createElement("div").innerHTML = " "; This raises the NO_MODIFICATION_ALLOWED_ERR error. Ok, so to summarize: When assigning to innerHTML of an element in an XHTML document, HTML entities are not recognized and result in an error. Created attachment 42156 [details]
Test case
This seems to demonstrate the behavior that you describe. Note that it also fails in Firefox with a similar error. Your summary is slightly incorrect in that these are also *XHTML* character entities - and that appears to be the context in which this bug surfaces. Also, it's not clear that the document needs to be served with the application/xml+xhtml content type. It certainly didn't in my tests. In my tests, the document was served with a DOCTYPE of XHTML transitional, and a content-type of "text/html" - so it seems that webkit, unlike all other browsers I tested, may have prioritized the DOCTYPE over the content-type. So you can apparently hit this bug in two different ways. The interesting distinction is that they’re not in the set of predefined XML entities. Does the test case accurately represent the problem you were seeing? Looking at Mark's example (and noting that as he says it fails in FF also) this may be a quirks mode difference (as I said, I'm serving this as content-type text/html). Let me run some tests and get back to you in a hour or two. Yes, Mark's testcase completely reflects what I'm seeing. And it turns out that I was also utterly mistaken in my earlier comment - I am, in fact, serving the file as application/xhtml+xml - the difference was in the weightings that you give to that content type (you prefer it over text/html) vs. what Firefox does (they give equal weighting, which my server tips to text/html). I apologize for my mistake. Very embarrassing, for my first filed Webkit bug. As you point out, you're bug-compatible with Firefox - you both fail if a user passes an XHTML character entity to an innerHTML of an XHTML document served as xhtml - even an entity that's perfectly valid per the DTD. Opera, however, does not fail - it handles assigning entities to XHTML innerHTML just fine. So, I'd argue that this is a valid bug, though you're in good company, and I expect to be filing a similar bug against Mozilla shortly. We seem to be in perfect agreement with the spec: <http://www.whatwg.org/specs/web-apps/current-work/#xml-fragment-parsing-algorithm>. But maybe the spec should be fixed to make fragment parsing respect target DTD. I'm not an XML guy, but isn't it true that if, as the spec says (from your link): declaring the default namespace (if any) that is in scope on that element in the DOM that that line requires that the entities that are declared in that namespace be respected? If it doesn't, then I agree that the spec is broken, because really, you should be able to feed any valid XHTML into the innerHTML property, and have it work. It shouldn't fail just because it has a valid XHTML character entity, but work for everything else. That's just dumb. Character entity reference handling is independent of namespaces - if you remove the top DOCTYPE line from your document, then won't be recognized even in static content. Note that conforming implementations may not recognize et al. even if a DOCTYPE is provided: <http://www.whatwg.org/specs/web-apps/current-work/#writing-xhtml-documents>. WebKit doesn't really parse external DTDs, but it knows common XHTML ones and enables XHTML character entity support for those. The editor of HTML5 specification is CC'ed on this bug, so this discussion may be enough to get the issue considered. But you can e-mail the WhatWG working group (or W3C HTML5 working group if you prefer) to be sure that it doesn't get accidentally overlooked. What the spec says is intentional -- external DTD parsing is optional in XML, and so entities can't be relied upon. I would recommend using numeric entities or HTML instead. We seem to be following the spec and our behavior matches other browsers. There doesn't appear to be anything to do here. Mass moving XML DOM bugs to the "DOM" Component. |