We Keep Coding

How to debug broken IE 8 when FF is fine

I spent a long time adding a lot of Javascript to our front-end. I did this all the while using FF (11.0). I just committed all the changes (which work fine on my local sandbox) to our dev server, and a QA tester noticed that an entire div is missing when viewing the page in IE 8.
This div does all sorts of fancy stuff with jQuery, allowing users to expand/collapse accordion panels, and drag-drop images from expanded accordions, etc.
It is 10 PM and I can't go to bed until I fix this break. I have tried using the IE Dev Toolbar that ships with IE (and is accessed via the F12 button), hoping it would catch some bad Javascript but nodda. Same for Firebug. The JS looks perfectly fine, it's just IE being stubborn.
What steps would SO take to start figuring out why IE won't display my jQuery-heavy div? It's really not as simple as backing out the changes one by one, because my code sprinkled and interwove functions and calls all over the JS page. Thanks in advance for any pointers or nudges in the right direction.

F12 Developer Tools
The F12 Developer Tools, when used properly, are generally speaking more than capable of finding odd problems throughout your code. You can audit your application to find long-running processes, add breakpoints and watch variables through the life-cycle of your page.
IE Compat Inspector(s)
Another great tool is the IE Compat Inspector, which will examine your code and look for any types of patterns or usage that might break your site in Internet Explorer. You can find this online at http://blogs.msdn.com/b/ie/archive/2011/04/27/ie9-compat-inspector.aspx for Internet Explorer 9, and http://blogs.msdn.com/b/ie/archive/2012/01/20/ie10-compat-inspector.aspx for Internet Explorer 10.
ECMAScript Compat Charts & Polyfills
Often times we mix up what features are supported by which browsers. It helps to keep a good compat chart handy, so you know if classList is supported in IE or not. If and when you discover that something isn't implemented in Internet Explorer, it's time to find a polyfill. Fortunately, there are many.
Web Debugging Proxies
These are just a few tools that you can use to trouble-shoot your site in Internet Explorer. Lastly is Fiddler 2 (a web-debugging proxy), which permits you to stand in between the client and server, tampering with data as it goes both ways. I typically use this to serve up custom files in the place of live server files when I'm debugging scripts. However, if you've got direct access to the server presently, this isn't all that necessary.

Cons of using Internet Explorer's Compatibility Mode

What are cons of force a web site viewed in IE to compatible mode? Say we force IE9 to IE8 compatiblity mode?
Performance drawbacks
Can't use any new IE9 specific features like HTML5/CSS3/SVG
Why?
We run legacy web app which is developed since 2000 so it's a mess ball fighting to be compatible with Chrome, Opera, Firefox, IE6/7/8 and now we decide to add IE9 to the list. But with IE9 we run in issues with printing, "Permission deniend" JavaScript errors (probably something about cross-frame JavaScript calls) and next issues - the easy workaround is to force IE9 to behave as a IE8 and then everything works fine. But I am still not sure if it's way to go...

first our app is public site (for our clients)
You have a public website developed in 2000 and it doesn't work on modern browsers? Deprecate it or re-write it.
Don't hack your code to support modern browsers, the website is clearly poorly written and doesn't apply to standards. You can't get away with this.
The only place where you can get away with this level of incompatibility is intranet applications and even then you should simply state "it works on browser X, live with it"
You can't say that to public facing clients. I mean you can try, but have fun losing business to your competitors.
Re-develop your website to match the W3C HTML/CSS standards and the ES5 standards and it will be completely future facing (for some years).
Alas, the way the web works is that anything more then 5 years old is deprecated. So either re-write it every 5 years or get out of the web business.
In terms of actually using compatibility mode, don't. IE6-8 are horrible engines and should be avoided like the plague. If you use them then you can't write future facing standards compliant code.
Your code needs to match the standards and you should fix / shim / patch any browser specific bugs where those browsers don't implement the standards.

You cannot say you have tested in IE6/7/8/9 until you have tested in those different versions. Emulating the test environment is not the same as using the test environment. To my knowledge IE7/8 compatibility modes are the older render engines, not the underlying browser as a whole, bugs and all. It is closed source so you will never know.
Convert Microsoft's free to download virtual disk images for cross-browser testing to Virtualbox images and put them on a machine that just runs Virtualbox. An old machine will do, run the VMs headless and access them with remote desktop. In that way you will be able to test in all browsers without burdening your machine with MS/Spyware.

I believe your system admins can set IE to compatibility mode for all intranet traffic using the Group Policy Editor. Any site you create will from this point forward, you can add a meta tag to force IE9 to render natively and use all the newer features...
I'm having to do that on my current project using the following doctype and meta tag in my header:
<!DOCTYPE HTML >
<meta http-equiv="X-UA-Compatible" content="IE=100" />

Compatability mode is something that MS introduced to give people some chance to upgrade their applications, not for long term use. AFAIU.
If you want your application to be compatible with IE9, then you will have to change it. If you are trying to maintain IE6-9 compatibility then you have a real challenge, and you should consider whether this is really practical - in essence, you need at least 2 distinct sets of html. Is this practical for you?
IE9 compatibility mode is different form IE9 and IE8 - it draws bits from both. So you need to do a full test agaisnt the compatibility mode version, and ensure that it remains working against this.
So in answer to the question, the cons are that you are not being IE9 compatible, and there is a danger that when IE10 comes out, your code will not run against that in any mode. You are putting the effort into compatibilty testing without providing for future changes. You would do better, in the longer term, to make your code IE9 compatible. Also, the message you are giving your clients is that your code base is not going to be compatible for much longer. Unless you are talking to them about a re-work, this is a real negative.
However, it sounds like your entire code needs a re-work, to forget about IE6 and be written for modern working browsers. Using compatibility mode until that happens is probably OK. If you do this - and tell your clients - then staying in compatibility mode is viable.

Using compatibility mode will NOT cause the browser to use the JavaScript engine that was present in the old version of IE.
By that I mean it will run any JavaScript code using the IE9 engine. Which was a problem for us when debugging an old product that had a problem with IE7/8.

Which web browsers give the most incompatability issues?

I'm not a 100% sure if I should be posting this here but where else can I post it (definitely not Server Fault or Super User) so hopefully it's not too inappropriate.
I am currently developing a script that I hope to release as a plugin for wordpress and other open source content management systems. The script's purpose is to allow web designers to attach stylesheets and javascripts dynamically according to which browser the visitor is using. So if their site looks a little odd in Chrome for example, then they can attach a css or javascript hack just for that one browser. There will be some more features to the script as well but that is the main purpose.
Anyway, I would like to know which browsers to include support for, for that I need to know which one's gives designers/developers the most trouble. Not just the name but also the version (i.e. Internet Explorer 4). Many thanks in advance!

IE6 is by far the most problematic of all browsers. Though it's use is declining month by month, it's still widely used. All IE browsers always suffered from display issues. Sometimes margins are not what they were set to, because you need to go down the css hierarchy to set all margins for it to understand what's going on. You shouldn't need to worry about anything below IE6.

There are many articles on the Net discussing this topic.
Here's an example

All versions of IE...Microsoft never likes to conform to W3C standards so they prefer adding hacks to "conform"
I know Opera browsers don't support CSS3 yet (latest release)....Have fun!

My vote as far as problematic browsers still in prevalent use would have to be IE 6.

Whenever anyone speaks of "browser compatibility issues", in almost all cases, the real problems are with IE. Markup written to web standards generally work well in any other browser save an occasional adjustment, but there are tens if not hundreds of web sites dedicated to hacking and fixing IE while there are none dedicated to doing the same. In fact, there are already javascript libraries for this very thing, getting IE to perform like other more modern browsers, such as Dean Edwards ie7.js and 'maximize' (I think it's called).
Most developers write to standards, test in the modern browsers, adjust if necessary, then, with a shaky hand open IE. Separate CSS and javascript for modern browsers is not necessary. While some may prefer to do so with IE, most of us make do with conditional comments and feed IE what IE needs to right itself.

Most people are designing for IE6+ these days, meaning that they are designing for W3C standards with IE6 bringing up the rear guard. Here's a fantastic site that breaks down all the features browser by browser, from IE6 on up.

Cross-browser development

I'm developing a web application for a new service, starting from Firefox 3.5.
The interface design is tableless, only using divs + CSS & performance-blessed practices.
Now, while being compatible with Safari has taken just a small amount of time, IE is a pain.
My question is: is there anything out there that could be used to speedup cross-browser checking? I already know many points of difference between FF and IE for instance, but a specific tool would maybe help some more.
Could you suggest one, if any?
Thanks,
Scarlet

Cross Browser Development
No tool can ever make up for bad behaviour, but they can sure make life easier on you.
That being said, you should really come up with a workflow that lets you optimize for cross-browser compatability in the least amount of work spent. If that means small iterative or large monolithical steps for you, well that is up to you to decide. But generally working against several browsers during development saves you if not time at least a major headache on d-day.
List of tools/resources I find useful
Selenium is a tool for frontend
testing
IETester lets you view
a page in different IE versions
Browsershots lets you view the
page on different platforms as well
Google lets you search for known and obscure IE perversions
IE 6 No More saves you a lot of headache not bothering about the preshistorical crap that goes by the name of IE 6
YUI Graded Browser Support - make sure you know which browsers to focus on
jQuery - cross browser javascript library
YUI 3: Reset CSS - reset your CSS (link contains useful information as well as the CSS)
9 Most Common IE Bugs and How to Fix Them - very useful tips on how to get the most bang for the buck by fixing the common problems first.
Cross browser development contains lots of useful tutorials regarding cross browser development.
References
Selenium alternatives / Cross Browser Testing / Litmus

This will not answer your question, but just an advice based on my personal experience.
When you are developing for many browsers, the best thing to do is to test simultaneously on all of them while you're coding.
This way you will just have to correct small bugs each time as opposed to overwhelming complicated layout problems.

I don't know of any software that actively check for problems, but Adobe has recently released BrowserLab, which really does speed up cross-browser testing.

I would also recommend using CSS reset. This way you get a lot of inconsistencies out of the way right from the start.

I do cross-browser development and I don't really use any of the prescribed patterns, like cross-browser testing. I instead use a decorative pattern. Sometimes it works wonderfully, sometimes it's a headache, but that can be said for any development pattern.
Most of my development takes place in which browser I consider the most standards-compliant. I prefer WebKit to Presto, but both are generally neck and neck for standards compliance. With these browsers, proper use of HTML and CSS almost always leads to desirable results. My WebKit browser of choice is Google Chrome. Safari works too, but keep in mind that on Mac OS X the font smoothing tends to make text bigger. To ensure compatibility with sites designed for Safari Mac, Safari Win emboldens fonts, so it's not always the most pixel-perfect representation of your site.
Blueprint CSS can be a huge help if you're trying to quickly prototype a cross-browser site design. I'm not convinced that such a framework is always necessary, and they can also influence the way you structure your XHTML markup, and contorting your markup to match a pre-existing CSS class hierarchy isn't always a great idea.
Once I have a design that I'm happy with in my standards compliant browser, I then decorate it with bug fixes in other, less standards-compliant browsers using conditional styles or stylesheets. Firefox, at least since version 3.0, is almost never a huge issue, but there are ways of targeting Firefox specifically, and even differentiating between Gecko 1.9 and 1.8, using only CSS. It's a hack, technically, so CSS purists might scoff at the code blasphemy, but it's a reliable, usable solution. For clarity and ease of maintenance, I usually maintain my Firefox/IE fixes in isolated stylesheets and compile them with some kind of server side script, which I consider preferable to conditional include statements and JavaScript hacks. If you make use of caching with PHP, this isn't a significant bottleneck or waste of CPU time.
IETester is an indispensible tool for checking a design in all of the different IE versions, and it even uses the proper JScript engine for each release, which previous, less reliable solutions like MultipleIEs lacked.
These days, the biggest problem with cross-browser development is JavaScript, and jQuery will basically save your life here. As someone who maintained a sizable JavaScript framework for a corporate website in the days before AJAX and JavaScript interfaces, so there's no limit to the amount of praise I can give for jQuery/Prototype/Dojo.

When you say only using divs and CSS, I hope you're not absolutely positioning everything. That's a sure-fire way to mess designs up in lots of browsers. (Generally the best practice is to use floats.)
You could also try IE7.js to fix a bunch of problems with IE 6-7.
In general I'd suggest developing in IE and one of the standards-compliant browsers side-by-side (Firefox/Chrome/Safari/Opera). And try and keep both the HTML and CSS as simple as possible.

A couple more tools include
Browsera - automatic detection of cross-browser layout problems
LitmusApp - screenshots with pass/fail tagging
SuperPreview - extension to Microsoft Expression Web (currently available standalone download) where you can view an overlay screenshot of a different browser
Browserlab - extension to Adobe Dreamweaver (currently available standalone online) where you can view an overlay screenshot of a different browser
I'd also strongly recommend using a CSS reset to start such as http://meyerweb.com/eric/tools/css/reset/
Why? Because many of the cross-browser inconsistencies stem from the fact that the default style in the browser differs. For instance, a default margin may make an element layout correctly in one browser, but not the others.
It may seem weird to always be overriding default behavior, because it seems like a waste, but its absolutely necessary in order to have a baseline with which to work.

I'd recommend looking at a CSS framework like BluePrint. It has a generic way to build pages using grids, and also has some default css for forms etc.
Frameworks will have dealt with many of these cross-browser quirks during their development, so it could save you a lot of time.

Design order: Firefox, IE, or both?

When coding new javascript heavy websites, which order or web browser do you code for?
I can see these possible orders, but I am not sure which I like best:
Code for one first and get it working well, then start testing with other and fix errors as I go.
This will allow for the most rapid development (with Firefox at least) but I've learned from experience that debugging IE with so much going on at once can be a pain!
Code for both at the same time. In other words, for each new feature, ensure it works with both browsers before moving on.
This seems like it will actually take more time, so maybe do several features in Firefox then move to IE to patch them up.
What do you all do?
Edit 1: To respond to a couple of answers here.:
#JQuery usage: For some reason I was not expecting this kind of a response, however, now that this seems to be the overwhelming accepted answer, I guess I should tell everyone a few more things about the specifics of my app. This is actually the DynWeb that I started another question for, and as I'm developing, a lot of the important code seems to require that I use document.whatever() instead of any JQuery or Prototype functions that I could find. Specifically, when dynamically importing changing CSS, I have to use some similar to:
var cssid = document.all ? 'rules' : 'cssRules'; //found this to take care of IE and Firefox
document.styleSheets[sheetIndex][cssid][cssRule].style[element] = value;
And I expect that I will have to continue to use this kind of raw coding currently unsupported by either JQuery or Prototype in the future. So while I would normally accept JQuery as an answer, I cannot as it is not a solution for this particular webapp.
#Wedge and bigmattyh: As the webapp is supposed to build other webapps, part of the criteria is that anything it builds look and work functionally the same in whatever browsers I support (right now I'm thinking Firefox and IE7/8 atm, maybe more later on). So as this is a more interesting (and much more complicated) problem; are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them? I'm almost certain that I am going to have to have some sort of isIE variable and simply perform different actions based on that, but I would like to avoid it as much as possible.
Thanks for your input so far! I will keep this open for the rest of the day to see what others may have to say, and will accept an answer sometime tonight.

This is sort of a trick question. In my opinion you need to work in this order:
1: Conform to Standards
This gets you closest to working in every browser without having to test against every browser. Additionally, you gain the huge benefit that your site should work with any new browser that comes along (Chrome is a good example) so long as it's well made and standards compliant. It also makes it easier to tweak your site to work in specific browsers because the way that the popular browsers deviate from standards compliance is well known.
2: Support the Most Used Browsers (For Your Site)
Note carefully the distinction between the breakdown of browser usage on the internet vs. browser usage on your site. On the internet as a whole IE is the most popular browser with Firefox a close second and Safari, Opera, and Chrome taking up most of the remainder. However, the demographics of your site's visitors can turn these numbers upside down. On sites that cater to a more technically savvy crowd it's common for firefox to be the dominant browser with IE in the distinct minority.
3: Support Other Browsers as Needed
You need to be very explicit about the fact that browser compatibility is an operating cost for your site, and you need to decide where you draw the line. Depending on your site's purpose and business model it may be fine to support only the most popular browsers, or even a subset of them. On the other hand, it may be a vital business concern to support everything under the Sun, including IE5. It's ok to make a conscious decision to not fully support every browser if you think the cost/benefit ratio is too high to justify it. Indeed, many of the most popular sites on the internet do not work well in older and niche browsers. Though you should strive to make your site still functional in the least popular browsers, even if there are serious appearance or usability problems.

FireFox first then IE. If it works in FireFox, it is more likely to work in the other non-IE browsers, IE sometimes requires special magic.

Use jQuery and do them all at once.

Code for Firefox first, but test with IE as you go. This lets you fix any quirks as they arise. It's important to test with Firefox first because it's more standards-compliant. You should learn how to write HTML/JS the right way. Fix things as you go to get a better idea of how IE renders things differently.
You may not need to test with IE for every feature you add, but test often enough so that issues don't pile on top of each other. Repeat with other browsers/browser versions to get the overall picture of your site's compatibility.

I always test on both FireFox and IE7. And then fix and botch for IE6 and other browsers.
If it works on FireFox it will almost certainly work on Opera, Safari, Chrome, etc with only a few minor tweaks
Same thing goes for IE7 and IE6, If it works on 7 it won't take too much to get a reasonable rendering on IE6
I normally use Firefox as my main development browser because of its superior debugging tools and I code very incrementally, write a few lines and test several times an hour. But at least every hour or two I make sure that what I am doing will work on IE7 as well.
As soon as I get into an area where IE7 causes problems I start to rethink the way I'm doing it, In my experience fixes tend to multiply and get out of control very rapidly. It's often better to accept defeat and move on with a simpler design.
I've been bitten too often in the past by developing something that works perfectly on FireFox only to find that it needs a complete rethink to get it working in IE7 as well - and vice versa. It can take days to sort out and can be very disheartening.

are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them?
A good resource for this is quirksmode. The author (Peter-Paul Koch, or PPK) has lots of compatibility tables for CSS and JavaScript support. He also has articles dealing with specific issues and how to write cross-browser code.
They don't deal with JavaScript, but Position is Everything is a valuable resource for CSS issues (mostly IE6).
Like others have mentioned, I just use jQuery to avoid these issues. If there's something it doesn't support, it's pretty easy to write custom plugins.

I do IE first, and then add Firefox.
My experience is that once it works in IE, it continues to work in IE, and the question why something not work in Firefox is usually easy to answer.

If you have to code for IE6, the most frustrating part is coding the CSS and HTML. jQuery and other libraries make it easier to code the behavior -- but you generally can't get around the fact that IE6 has so many weird rendering issues that you'll be frequently banging your head on the keys trying to make it do what Firefox, Safari and Opera do right the first time.
So Javascript isn't the hardest part. Dealing with HTML and CSS is. In my experience, if you're working with any reasonably interesting design, you're better off coding for IE first and then testing on Firefox. You probably won't have to make many adjustments if you do IE first, but you definitely will have to spend some time refitting your code to make IE do what you wanted it to, if you only code in Firefox. It's like repeating yourself. It's a pain. So it's better to get it done first so you don't end up wasting too much time.

I code for both, and write (or use) abstraction layers where there are differences between the browsers. IMHO, it's much easier in the long run to be continuously testing in a cross-platform setting. This keeps me from doing something that's tuned to one browser that simply won't work well in the other: I find out very early in the development cycle what the compatibility issues will be.
When I'm making a small change, I might first do it for one browser, but before I consider that feature or change to be complete, it must work at least in firefox and IE.

To minimize your issues now, and downstream, work with the worst to the best, in size of their existence.
Edit: If you can do the below keeping in mind of "how could this degrade gracefully down to ie6 via modified jQuery elements, etc... it might be a bit clearer.."
So, today based on Market Share, it is:
1) IE 6
2) IE 7
3) Firefox
4) Safari..etc.
Coincidentally enough, the major issues with browsers occur in that order too.
This means the majority of the issues your users will face will be in that order, and in those proportions.
On our team I have banned initial-development testing in Firefox. It has to survive the weakest link, not the strongest. Inhumane, I know, but we have cut down going back and fixing bugs related to browsers by 80%, because 80% of browser bugs are IE. Yeah, there's a ton of debugging tools in Firefox that can be used ONCE we find a problem in IE.
On the flip side we put in extra-features that are Firefox only to reward the firefox users. A simple browser type check and it takes care of the rest.

If you have look at Web Browsers market share, you will find that IE and Firefox are on the top and so close to each other so,
You should put both of them in your consideration either using cross-browser Javascritp like JQuery or go on your way by testing both of them.

I think its best to design for Firefox but like others have mentioned the JavaScript isn't the hardest part, its the CSS that is the hard part. Personally I used to code for both FF and IE at once, but I find that it takes longer because your likely to make major changes during a development cycle so don't even bother coding for both at once, it could be wasted effort.
Another thing to consider when choosing which browser to start development under is if you are more familiar with W3C standards or the IE "standard" imposed by its majority user base. Its kind of a funny thing about web standards, many if not most web developers are not happy with IE's standards support, but at the same time any code IE supports is the real standard of the web.