Bug 1: Ajax post request
How do you debug that? You can see that there's no POST data coming through, but you also know the script sending the data worked until recently - and you know the script hasn't changed. What you don't know is that the server was upgraded - but you learn this after about 1 hour. However, you do know that Chrome sends the data through just fine - but IE and Firefox don't. Where do you start looking for the problem? Nowhere do you get any errors (PHP doesn't notify you that the data from the POST request was dropped - and the browsers don't tell you that the request is faulty), so you have to guess at what the error might be.
What led me to the answer was that Google Chrome detected the problem and fixed it - although silently. Chrome rewrites the boundary identifier before sending the request through - if it detects a faulty boundary identifier. So when I tried googles boundary string, suddenly things worked. A bit of experimentation later and I had the solution - which also led me to the changelog for PHP 5.3.9, where this thing is mentioned.
Bug 2: cloning in IE9
The second bug that caused me massive headaches was cloning DOM elements in IE9. I do the cloning in order to send back html to the server, for converting to PDF. Turns out that it's much, much, MUCH easier to deal with the html through the DOM (and especially through jQuery or other such libraries) than it is to deal with it through PHP. So what is done is that the main node is cloned, various bits/pieces removed and then the content is sent through a request as a text string. How could this go wrong, you ask? Well, turns out that IE9 decided to throw hissy fits and just randomly apply classes to elements. Well, not quite randomly: in the process of cloning, it came across one class-name it liked so much, that it decided to apply it to about 75% of all elements on the page (but not all the elements - that would have been too consistent).
What fascinates me about this is that all other browsers I have tried work just fine. Yes, that also means IE7 and IE8 (we don't cater to IE6 on the project) - no trouble there. Microsoft actually worked hard to make sure that there were new bugs in IE9. Well, I suppose the world wouldn't have been the same if one of their browsers actually worked as it should.
Of course, this is exaggerating things. Most likely, the fault is mine for cloning elements with IDs. Still, I think Microsoft got the golden rule of interoperability wrong (the one that goes something like: "be lax on your input but strict on your output"): instead of being lax about input, they decided to be strict about it ... while they in general are rather lax about their output (another example of this sending a response to an ajax request - you had better not think to set the charset to utf8, as that will just result in errors you have no idea how decipher).
What makes me think that? Well, the fact that my hacky workaround works: grab the string representation of the node to clone, add an extra bit to all IDs, then create a new element from that and start working. And hey presto, problem solved. Do I feel dirty now? Yes. Is my loathing of IE and MS bigger? Yes. Was I fooled again by them, thinking that IE had in fact improved? Yes. Shame on me? Yes.
In fact, the error handler only served to confuse things, because it has picked up on a number of bugs, including errors in browser plugins and weird script handler issues in the Bing crawler. I don't regret putting it into place but certainly needs a lot of analysing before it gives off any goodies.
In the end, only lucky guessing and some deductions provided answers. Of course, various tools could probably have helped, but I would have needed to know that these would be useful in tracking down the error - so I would still have had to guess at the problem. I have learned a bit more about browsers, and - most importantly - about errors. The worst possible error is the one disguised as success: either your typical silent error (such as dropping the POST vars without mentioning it) or your more atypical everything-is-fine error (where things fail but appearances are kept up).