30923 2009-10-29 13:16:35 -0700 When assigning to innerHTML of an element in an XHTML document, HTML entities are not recognized 2019-02-06 09:02:32 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) All All RESOLVED WONTFIX P2 Major --- 1 maus webkit-unassigned abarth ap cdumez ian janderssn mrowe oldest_to_newest 159031 0 maus 2009-10-29 13:16:35 -0700 The following code: var element = document.createElement("div"); element.innerHTML = "test &nbsp;"; 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. 159036 1 mrowe 2009-10-29 13:22:13 -0700 Can you please provide a complete test case that demonstrates the problem? In my quick test the JavaScript snippet behaved as I expect. 159117 2 janderssn 2009-10-29 15:33:29 -0700 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 = "&nbsp;"; This raises the NO_MODIFICATION_ALLOWED_ERR error. 159119 3 mrowe 2009-10-29 15:38:06 -0700 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. 159122 4 42156 mrowe 2009-10-29 15:41:56 -0700 Created attachment 42156 Test case 159124 5 mrowe 2009-10-29 15:42:33 -0700 This seems to demonstrate the behavior that you describe. Note that it also fails in Firefox with a similar error. 159126 6 maus 2009-10-29 15:46:47 -0700 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. 159127 7 mrowe 2009-10-29 15:49:41 -0700 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? 159129 8 maus 2009-10-29 15:50:29 -0700 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. 159174 9 maus 2009-10-29 18:01:51 -0700 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. 159231 10 ap 2009-10-29 23:23:51 -0700 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. 159335 11 maus 2009-10-30 10:15:24 -0700 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. 159353 12 ap 2009-10-30 10:36:51 -0700 Character entity reference handling is independent of namespaces - if you remove the top DOCTYPE line from your document, then &nbsp; 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. 159358 13 ap 2009-10-30 10:42:55 -0700 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. 159485 14 ian 2009-10-30 15:35:04 -0700 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. 278598 15 abarth 2010-09-13 17:49:32 -0700 We seem to be following the spec and our behavior matches other browsers. There doesn't appear to be anything to do here. 1502791 16 lforschler 2019-02-06 09:02:32 -0800 Mass moving XML DOM bugs to the "DOM" Component. 42156 2009-10-29 15:41:56 -0700 2009-10-29 15:41:56 -0700 Test case test.xhtml application/xhtml+xml 349 mrowe PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIg Imh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5kdGQiPgo8aHRt bCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+CiAgICA8Ym9keT4KICAgICAg ICA8ZGl2PkZBSUw8L2Rpdj4KICAgICAgICA8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+ CiAgICAgICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdkaXYnKVswXS5pbm5l ckhUTUwgPSAiUEFceDI2bmJzcDtTUyEiOwogICAgICAgIDwvc2NyaXB0PgogICAgPC9ib2R5Pgo8 L2h0bWw+Cg==