Defining The Vomit Bug

The more I test HTML 5 and the more I play around in the DOM, the more I find odd situations that will trigger particular bugs.

The one result I’m seeing is what I’m now referring to as a vomit bug.

Definition

Vomit bug
When the browser’s parser rearranges the DOM completely differently to the markup, resulting in content being placed outside its original container.

Examples

For example, due to a bug in Firefox 3.5.2 (and perhaps before) the following markup is subject to the vomit bug:

<a href="#">
  <section>
    <p>p nested in a section wrapped in a link</p>
  </section>
</a>

The resulting DOM is as such:

<a href="#">
  <section></section>
</a>
<p>
  <a href="#">p nested in a section wrapped in a link</a>
</p>
<a href="#"></a>

This is a particular bug in Firefox that triggers when it parses a section element nested inside an a element that causes all currently open element to close, and the contents of the section element has been “corrected” by the browser and the DOM rearranged.

Note that by using the html5.enable option in Minefield renders correctly.

You can see a live example here: http://jsbin.com/upiza

The old Gecko engine (for Camino and Firefox 2) suffers from the same vomit bug when introducing new (or HTML5) elements (which can be fixed by serving as XHTML).

What other vomit bugs have you found?

10 Responses to “Defining The Vomit Bug”

  1. I’ve experienced this with <header > and a couple of other of the HTML5 block-level elements in FF3.5

    Additionally – FF3 did a similar thing to some (admittedly badly formed) HTML4 – although it ‘looked’ okay in FF and like vomit in IE (which had decided to deal with the badly formed HTML in a different way).

    Still – good to now that fixes are already on the way.

  2. I think you’re referring to a bug in gecko were parsing block level elements within inline elements is dependent on packet boundaries. It was mentioned by Eric Meyer http://meyerweb.com/eric/thoughts/2009/01/02/an-event-apart-and-html-5/. I could be wrong though.

  3. Does it do that for any other inline-only-but-now-also-block wrappers? I’ve heard arguments that <small> should be able to wrap blocks, but there was argument and I’m not sure if it’s ever been implemented.

  4. @Stephen – I’m not quite sure we’re talking about the same thing, but take a look at the camino screenshot I took and you’ll see the vomit bug in action with new HTML 5 elements in the old Gecko render engine).

    @Michael – in the example I gave above, Firefox only bugs out when you nest the section element inside the a element (so far as I’ve tested and reported).

    Regarding the small argument, I actually just posted on that topic the other day on the WHATWG mailing list – go get stuck in there!

  5. Hello,

    It’s worth noting that the new HTML5 parser bundled in Firefox 3.6a solves this bug. Right now, this new parser is disabled and you have to toggle html5.enable in about:config to use it (they you can just load a new page or reload the page you were testing). I’m not sure whether it will be enabled by default in Firefox 3.6 final.

    Screenshot of a correct DOM in Firefox 3.6a with Firebug 1.4 (had to hack the max version thingy to get it installed).

  6. @Florent – absolutely – and I did state this in the post for this particular blog post (and I also pointed it out in the bug report I sent to Mozilla on this specific bug):

    Note that by using the html5.enable option in Minefield renders correctly.

    The big question is whether or not it will be turned on by default. My gut feel is that they may shy away from it, but I’d very much like to be wrong.

  7. I can reproduce the bug, and a workaround is to put a div as a child of the link; however this will still be subject to the packet boundary bug.

  8. I just realised that this is exactly what I found recently; Block-level links, HTML5 and Firefox. It seems to apply to all non-HTML4 elements for me (ie new HTML5 semantic elements as well as made-up elements).

    Did you file this in Bugzilla? If so what’s the number—I can’t seem to find it…

  9. I just realised that this is exactly what I found recently; Block-level links, HTML5 and Firefox. It seems to apply to all non-HTML4 elements for me (ie new HTML5 semantic elements as well as made-up elements).
    Did you file this in Bugzilla? If so what’s the number—I can’t seem to find it…

  10. I just experienced a very similar bug (very frustrating) when I did my new blog theme. On the front page, I wrapped a few elements (h2, div and a span) inside one big <a>.

    I experienced the vomit bug, but inconsistently. It seemed to occur much less frequently when I hit refresh than when I hit enter from the address bar.

    I tried wrapping the contents of my link in an <article> tag (why not?) but now experienced the bug consistently. I found that wrapping that <article> tag in a <span> tag completely solved the problem.

    … but of course that is not valid HTML, and it’s one tag too many.

    EDIT: I was just reading up a bit more about the problem I initially had, and it seems it’s the infamous packet boundaries problem.

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight