In general, I agree. Unfortunately, detecting some bugs is either a lot of work or almost impossible -- you can't, for example, generate DOM events programatically, so bugs in event handling are very tricky to test for.
On the bright side, it is often possible to write your fix in a non-invasive way, or adjust your code to not depend on the buggy behaviour. (For example, some browsers will still fire a keypress event if you cancel the corresponding keydown event. My code editor[1] ended up checking again in the keypress handler for keys that should have been handled, and cancelling them again.)
And just today, I had to fix a Firefox bug where the cursor in an editable document would be displayed in the wrong place. Note that this is purely visual -- it acted as if it were in a different place than it showed. Good luck detecting that. So yes... there we go again: /Gecko/.test(navigator.userAgent)
Given the above analysis, we now understand the bug well enough to try to write some code to detect it.
This is exactly as it should be: the burden should be on the browser developers to investigate bugs and write the tests they want web developers to use in their workarounds.
Actually, my experience is different. This was a year ago, so maybe they've improved, but my detailed bug report was anwered with a dumb question that showed the person had hardly read it, and then when I asked whether they could let me know when a version without this bug was released (the issue was completely blocking Opera support in my system), I was completely ignored.
On the bright side, it is often possible to write your fix in a non-invasive way, or adjust your code to not depend on the buggy behaviour. (For example, some browsers will still fire a keypress event if you cancel the corresponding keydown event. My code editor[1] ended up checking again in the keypress handler for keys that should have been handled, and cancelling them again.)
[1] http://marijn.haverbeke.nl/codemirror