WebKit thinks <a id="blah" /> is an opened tag that doesn't have a matching closing tag. The attached test shows the problem.
Created attachment 23225 [details] Test case The attached test xhtml file shows the problem - test1 shows up as test2's parent when it should be its sibling.
Your MIME type is causing the page to be parsed as HTML, not XHTML. That said, it's not valid XHTML either. Making the minor tweak necessary to cause it to parse as XHTML and serving it with the correct MIME type leads to it displaying "bug not found" as one would expect.
I believe that WebKit's treatment as the document served as text/html is correct per the HTML 5 parsing algorithm. Pasting the source into the HTML 5 Live DOM Viewer at <http://livedom.validator.nu/>, you can see that the DOM places test2 inside test1.
This is invalid. Serve your page with an XML or XHTML MIME type.
I'd argue that <?xml and XHTML DOCTYPE should be a good enough indication that the document should be treated as XHTML (maybe with a fallback to the current behavior if the document turns out to be not well-formed XML) - especially in a context where a mime type is not available at all (e.g. reading the file from the filesystem or even writing it directly into the WebKit widget). The test case works correctly in Firefox regardless of the way it is read.
Both Safari and Firefox treat this document as HTML. There are many reasons for HTTP headers to prevail over XML declaration, so no major browser treats content transferred as text/html as XHMTL. This document is rendered in Firefox as "expected" because Firefox follows different rules for processing invalid markup. WebKit matches HTML5, which you can confirm yourself by comparing output of <http://software.hixie.ch/utilities/js/live-dom-viewer/> and <http://james.html5.org/parsetree.html> in both browsers. You can also see that Firefox will render the document the same if you remove the ending slash, as it is ignored anyway.