I really thought js libs meant we didn't need to worry quite so much about cross browser quirks so much any more.
Writing some Selenium functional tests, it turns out that's not true.
I have a table. A simple table. With a header, footer, and body content. With the html in the correct order, as it should be, thead then tfoot then tbody.
In my Selenium tests I generate a lot of tables. I don't want to compare them cell by cell, so I'd taken the (what I thought to be) neat approach of grabbing the text the first time the test runs, saving it in a file, and then comparing subsequent runs with this known good.
It turns out that when running the test on Firefox, a call to $element->text() returns the text, without any html, as it appears on screen - that is, thead content, followed by tbody content, followed by tfoot content.
In Chrome, it returns the text, without any html, as the html is - that is, thead content, followed by tfoot, followed by tbody.
For the record, on IE it does the same as Firefox. (This all on a Win7 VM, IE10, Chrome/FF latest).
Which means the tests ALL FAIL when they shouldn't.
Which feels like trying to write cross-browser js all over again. Painful.
I was wrong. I jumped the gun.
I've yet to look into why the html ends up different in the different browsers; it's possible that's where the bug is.
Anway, what I have learned: don't file bugs on a Friday afternoon. Make sure your error report actually produces the error.