Here’s what happened: I was working on the Frost Ajax Library and using Safari Version 3.0.4 (523.12) for testing things.
The document, index.php, was serverd to the browser using this content-type header: “application/xhtml+xml” and the DOCTYPE was “-//WAPFORUM//DTD XHTML Mobile 1.0//EN”.
Now in Frost here’s a simple function that can put some text or HTML to a container, basically using simple innerHTML like this:
//id and cont are passed to the function
var ob = document.getElementById(id);
ob.innerHTML = cont;
The strange behavior appeared when cont was empty. In this case Safari throws an exception: NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7.
There is no exception thrown if cont is not empty though.
If you serve the document with content-type headers as “text/html” there is no exception and everything works as it should.
The consclusion so far is that Safari has a bug and rejects to see an empty string as a valid value for a container, apparently only when the document is pure XML.
A quick search produces some similar issues floating around the web since a couple of years.
As a workaround my current solution is to encapsulate cont with proper tags like this:
//id and cont are passed to the function(<_span_> should be <span> really – needed for showing this code)
var ob = document.getElementById(id);
cont = "<_span_>"+cont+"<_/span_>";
ob.innerHTML = cont;
Could make sense in one way, because documents served as real XML should be handled more restrictive and modifications should produce valid XML documents again. However if I just want to put some text in a tag and if this text happens to be empty this should work too. So why is Safari making a difference if the value filled into a tag with innerHTML is empty or not – is this a bug?
November 23rd, 2008 at 4:23 pm
You were one of the top coherent hits for ‘NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7′, which has been giving me bizzare trouble with Webkit when it comes to writing innerHTML for a STYLE tag (I’m trying to build dynamically generated CSS stylesheets). As far as I can work out Webkit’s DOM believes a lot of proper XML XHTML tags are read only. Not the most helpful comment to a year-old problem, I know :). I’m getting arround it by defining another variable, copying the current innerHTML if needed, deleting the original element and then replacing it. Ugly but least roundabout way I can find of dealing with this seemingly unsolvable problem.
November 24th, 2008 at 1:30 pm
thanks barney, seems like this problem never gets old ;) maybe you could provide a little code listing? i could add it to the original post.
May 13th, 2009 at 10:32 am
For dynamic CSS you can use “innerText” property of STYLE tag object. It works without any errors.
May 19th, 2009 at 4:59 pm
Thanks a_[w], that did the trick for me!
March 22nd, 2010 at 11:36 am
Works for me too. Thanks a_[w]!
July 22nd, 2010 at 7:03 pm
Hi all,
The problem sometimes, as eluded to above, is that you can’t modify elements with .innerHTML or use other element modification methods (document.write() I think) when the page is served as XML. That is content-type ‘application/xhtml+xml’. This is true for many browsers (all?), including Chrome that can read true XML pages. So pages served as XML will error on .innerHTML, unless you create the element in javascript, append it the the document and then use .innerHTML. Why it works for added elements and not existing ones is beyond me, but oh well.
Otherwise the problem might just be as stated, that you are trying to modify something that doesn’t (clearly) exist yet, is considered ‘read only’ or something.
So what to do it the first case of an XML page?
I found this on the web:
BetterInnerHTML v1.2, (C) OptimalWorks.net
Just google the above for the latest version of their .innerHTML replacement code. Works great for me, although I did modify it for may own purposes (made a Dojo style module of it). It uses simple DOM munipulation to accomplish the same thing as .innerHTML.
Hope that helps others who follow this error.