Bug 30923 – When assigning to innerHTML of an element in an XHTML document, HTML entities are not recognized

• Component: DOM
• Status: RESOLVED WONTFIX

[Jim Driscoll]

The following code:


var element = document.createElement("div");
element.innerHTML = "test  ";

Throws the following error:

NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7: An attempt was made to modify an object where modifications are not allowed.

This is something of a problem for us (JavaServer Faces Ajax support).

XML entities work fine, but XHTML defined entities, as defined here:
http://www.w3.org/TR/xhtml1/dtds.html#h-A2

Fail.

This is a rather serious problem, and from looking at more than a few JavaScript libraries, it appears that they have not found a workaround.

I tried working around it myself, by creating a contextual fragment, but that just gave a Dom Exception 9 error.

Note that all other tested browsers handle this Just Fine.

Since there is no workaround, I've requested this be a P2.

[Mark Rowe (bdash)]

Can you please provide a complete test case that demonstrates the problem?  In my quick test the JavaScript snippet behaved as I expect.

[Joel Andersson]

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.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

Created attachment 42156 [details]
Test case

[Mark Rowe (bdash)]

This seems to demonstrate the behavior that you describe.  Note that it also fails in Firefox with a similar error.

[Jim Driscoll]

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.

[Mark Rowe (bdash)]

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?

[Jim Driscoll]

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.

[Jim Driscoll]

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.

[Alexey Proskuryakov]

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.

[Jim Driscoll]

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.

[Alexey Proskuryakov]

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 &nbsp; 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.

[Alexey Proskuryakov]

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.

[Ian 'Hixie' Hickson]

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.

[Adam Barth]

We seem to be following the spec and our behavior matches other browsers.  There doesn't appear to be anything to do here.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.