Problems

Firefox NS_ERROR_INVALID_POINTER with innerHTML

When trying to use prettify here on Defective Semantics I ran into problems with firefox. Here are the errors from the error console:

Error: undefined entity
Error: uncaught exception: [Exception...
 "Component returned failure code: 0x80004003 
 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]"  
  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"
  location: "JS frame :: hxxp://example.net/prettify.js :: 
             replaceWithPrettyPrintedHtml :: line 1414"
  data: no]

My insistence on trying to use XHTML on the blog is partly to blame. Prettify tries to add “ ” entities to the source (even if it’s a pre element) to appease Internet Explorer. This entity only semi-works in XHTML: I’ve run into similar problems with some HTML entities not being loaded, because some browsers don’t load the DTD (which in turn loads the entity sets). It also appears that while Firefox claims to support HTML latin 1 entities in a document with a PUBLIC XHTML identifier, it doesn’t actually reparse innerHTML assignments according to those rules.

My solution is to add a conditional test for XML. Having a look at the Javascript document object there doesn’t seem to be a reliable way to detect whether the browser is treating the document as XML from javascript. My best attempt was:

document.xmlVersion && (document.compatMode=='CSS1Compat');

which works for Firefox and Opera.

As a separate issue, Chrome and Safari (and presumably anything WebKit based) don’t allow assignment of innerHTML for XML documents, giving NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7.
Fixing prettify to use only DOM methods instead of building up a string and assigning it to innerHTML could be a lot of work. At least this exception, unlike the Firefox error, doesn’t leave the pretty-printed block in an inconsistent state.

I submitted a patch to the prettify issue tracker.

PHP DOM XML default namespaces

Anyone that’s used PHP’s DOM XML knows that it’s a deprecated, buggy PoS. An undocumented memory leak in DOM XML resources and an equally undocumented workaround to manually free them are plenty of evidence for this. Spare a thought for those of us who are on supported RHEL4 and stuck with PHP 4 and hence the DOM XML API.

My gripe today is with create_element_ns. Terence Kearns has a pretty good summary of the issue in his comments. Essentially, you cannot add a namespace to a node with the default prefix in a way that is recognised by the rest of DOM XML. The problem is that supplying an empty $prefix parameter to create_element_ns is treated the same as omitting the $prefix parameter altogether, in which case DOM XML generates a random prefix.

The libxml2 convention is that passing a NULL prefix to xmlNewNs binds the default namespace, while passing an empty string is illegal. Unfortunately, this convention might break a lot of PHP code that relies on DOM XML generating random namespace prefixes, because people are more likely to omit $prefix than to supply an empty string when they want the random-prefix behaviour. However, I figure it’s better to break lazy code than to invert the libxml convention.

My patch changes the DOM XML behaviour so that an empty string prefix such as $doc->create_element_ns('foo', 'http://example.net', '') activates the old DOM XML random-prefix:

   <a1337:foo xmlns:a1337="http://example.net" />

while omitting $prefix altogether as in $doc->create_element_ns('foo', 'http://example.net') binds the default namespace:

   <foo xmlns="http://example.net" />

blogger not processing openID delegation

It was pleasant to discover that blogger.com (now part of the Google conglomerate) started supporting OpenID comment authentication last year.

However, at some point in the last couple of months it stopped working for me; I get the error code bX-m9h15s when trying to authenticate. As far as I know, my OpenID server is working just fine (OpenID Checkup agrees).

If I use my server URL directly (instead of an HTML resource that uses delegation) it works, albeit without incorporating any of the Simple Registration data. There are plenty of other reports, but nobody competent (and/or employed by google) has responded.

There doesn’t seem to be a true bug reporting facility for blogger; the competent users help the incompetent users on the discussion forum, but I can’t see any developer or even QC presence there.