views:

144

answers:

4

My company makes its money off of a great user experience using IE6, 7, Firefox and Safari. 90% of our traffic ends up IE and probably 60% of that traffic is still IE6. IE6 has a bunch of known gotcha's such as accessing DOM objects while they are still being inserted crashing the browser. Almost none of these issues surface during routine testing, they almost always include some odd timing race condition that only affects our most important client of the week.

What process or tools do you use to ensure that known patterns that crash IE are not present in your code?

Added: For those suggesting sticking to 3rd party libraries: I agree that it will help a lot, but you still have to glue those APIs together with Javascript. Is there anyone that is not just crossing their fingers and waiting for someone out in the wild to let them know that there code has just crashed their system?

+1  A: 

We don't worry about it. Instead, we use a third party tool like jQuery (well, EXACTLY like jQuery in our company) to ensure cross-platform idiosyncrasies are handled.

paxdiablo
Yea, we use AJAX.NET + prototype but are moving to AJAX.Net + JQuery. Still get about one killer bug a quarter that forces us to rejigger or patch around the libraries.
Brian Adams
+1  A: 

I recommend you rely on as many popular 3rd party frameworks as you can. They've undergone far more revisions and testing than you can ever perform. Obviously this means you should be using jQuery for all your JS related work.

Unfortunately there is no silver bullet for these browser bugs, as long as you go with JS & HTML you will continue to have these gotchas. At best you can compile a list of them, publish them on a blog, let the community discuss them and make sure all your devs learn them.

This is an example why Flash and SilverLight exist, which may seem like shocking suggestions considering you've spend an unmeasurable amount of time developing your UI, but if you want to be free of browser/OS bugs, going with a 1 company delivery package is the only way to break the 99.9% barrier for web bugs.

TravisO
+1  A: 

I do a try on window.event.srcElement (which'll only work in IE) and put the non-IE stuff inside the catch, and tie stuff up in my finally.

All other browsers seem to throw an exception with window.event.srcElement so I use that line first and if it gets passed that line it'll obviously be IE so I place my IE code there, if it ever goes to the catch it's clearly a browser that is a bit more standards compliant so I put the alternate code there.

This has saved my ass a lot when it comes to writing Javascript events dynamically using server side code that involves mouse events.

Hope that helped, gives you a way of supporting multiple browsers with different code without server-side detection.

Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.

Shahin
The core jQuery functions will work on all the browsers that the library states it supports, can you be specific when you say some functions don't work on all browsers?
micmcg
A: 

Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.

Ofcourse, if you relate to IE5 or NN4, jQuery may not be the best pick. Otherwise, you won't have a problem with this. I use jQuery for a HUGE site and i don't have problems with library. I have problems with plugins, but this is a different story. And btw, i have less than 10 lines of pure js in my files. If you learn to use jquery efficiently, you won't need any js knowledge (sounds weird, but... this is my case :P )

Ionut Staicu
i really apreciate the negative rating, but if i will have an explanation would be even nicer
Ionut Staicu