Fixing Google Chrome Compatibility bugs in WebSites - an FAQ

This document provides a concise list of common compatibility issues with Google Chrome along with their solutions. It's aimed at Web developers trying to fix compatibility issues with Google Chrome or interested in a list of things to avoid when authoring Websites to use in Google Chrome.

The list is based on analysis of a large number of real-world sites with compatibility issues. It's important to note that in nearly all cases we've seen, the fixes required to get a Website working well in Google Chrome have been minimal. Developers are often surprised that problems that looked like they could take weeks of developer time were often solved in under an hour and matched closely with the list below.

Each item is described along with its solution, at the end we have a section that lists useful tools and points of reference that you may find useful in diagnosing problems.

Preamble - Google Chrome's rendering Engine:

Google Chrome uses WebKit (http://webkit.org/) to draw Web pages. WebKit is a mature (~9 years) open source layout engine used by Apple (Safari, iPhone), Google (Android, Google Chrome), Nokia and many other companies. Google Chrome aims to render sites exactly like Safari. This means that if your site works in Safari there is a large chance it will work in Google Chrome and vice versa.

Common Issues:

• UserAgent Detection
• Paragraphs Overflowing/Text Cutoff
• Correct page encoding
• Correct Plugin Tags
• Inline elements can't enclose block elements
• Use of Browser-Specific CSS or JavaScript objects
• Useful Tools
• Additional Resources

UserAgent Detection

The Symptom

• Do everything you can to avoid this, parsing navigator.userAgent and navigator.vendor is notoriously bug-prone and usually the wrong thing to do! Object detection is a much safer method to achieve per-browser behavior...

• On Windows, Google Chrome's useragent string looks something like the following:

     Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/2.0.167.0 Safari/525.13

In nearly all cases you don't want to check if you're running under Google Chrome, but if the browser is using the WebKit rendering engine (see above). If you must look at the navigator.userAgent string look for the substring 'AppleWebKit', nothing else is guaranteed to continue working in the future!!

var isWebKit =
  navigator.userAgent.indexOf("AppleWebKit") > -1;

isWebKit will be true if you're running in Google Chrome, Safari or any other browser using WebKit.

To check the version of WebKit, use:

var WebKitVersion =
  parseFloat(navigator.userAgent.split("AppleWebKit/")[1]) ||
  undefined;
if (WebKitVersion && WebKitVersion > 500 ) {
  // use spiffy WebKit feature here
}

You can find a list of Google Chrome Releases and their corresponding WebKit revisions here.

• Avoid code like the following:

if (isChrome) {
    doSomethingChromeSpecific();
} else {
  // Didn't detect browser type, so assume IE.
  doSomethingIESpecific();
}

The problem is that the above snippet assumes that any browser not explicitly identified is IE. The problem is that it's far more likely for other browsers to act alike than it is for them to act like IE. Instead make IE the special case. This helps to make your site future proof:

if (isIE) {
    // Much Safer!
    doSomethingIESpecific();
} else {
  doSomethingChromeSpecific();
}

Paragraphs Overflowing/Text Cutoff

The Symptom:

Correct page encoding

The Symptom:

• Declare your page's content-type correctly, this can either be in an HTTP header or a Meta tag specified in your HTML.
• The character set your page uses must be a legal value from the Official IANA List, please only use the encodings that have the text (preferred MIME name) listed next to them e.g. ISO-8859-1, Shift_JIS.
• If you specify two different values for the character encoding in the HTTP Header and the Meta tag, Google Chrome will use the value in the HTTP Header. Conflicting declarations of character encoding in the HTTP Header and Meta tag is asking for trouble. More information on this subject can be found here.
• We recommend using UTF-8 for all Web content. If you have to use legacy encoding for some reason, make sure to identify the encoding correctly as outlined above. For legacy situations involving Hebrew sites use Logical Hebrew encoding (ISO-8859-8-I). We strongly discourage the use of Visual Hebrew encoding (ISO-8859-8). It has no place on the Web anymore and is a remnant of old systems lacking logic for rendering RTL text. It causes many bugs and lots of confusion.

Correct Plugin Tags

The Symptom:

<object ...>
    <param name="src" value="flash_ad.swf">
    <embed src="different_file.swf" ...></embed> 
</object>

Inline elements can't enclose block elements

The Symptom:

HTML defines what are called "block elements" (such as <div>) which represent a "square" on a page and "inline elements" which flow with the page layout (such as <a> and <span>). It is illegal to enclose a block element in an inline element. Different browsers will try to "fix" the markup for you in different ways if you do try to do so. This can cause the page style to be displayed differently between browsers.

Recommendations:

1. Make sure to properly close inline tags such as <a> and <span>. Forgetting to close a tag can often lead to this situation. There exist a variety of tools you can run, both online and locally to validate your markup and make sure all tags are properly closed.
2. Here are some examples of bad markup and the correct way to achieve the same effect:

<!-- Illegal for <a> to embed <div> -->
<a>
  <div>
     some text
  </div>
</a>

<div>
     <a>some text</a>
</div>

<!-- <span> is an inline element and <form> is a block element -->
<span style="visibility:hidden">
    <form>
        ...
    </form>
</span>

<div style="visibility:hidden">
    <form>
        ...
    </form>
</div>

Use of Browser-Specific CSS or JavaScript objects

The Symptom:

• Do not use document.all in JavaScript. This is an outdated IE feature, all modern browsers support document.getElementById() and you should use that instead.
• When diagnosing JavaScript issues, use Google Chrome's built-in JavaScript debugger.
• Do not use browser-specific (e.g. -moz-*, -webkit-*, -ie-*) css selectors such as -moz-center or -webkit-highlight for critical visual features of your site, instead use standard CSS.
• Do not use CSS expressions (e.g. width:expression()). These only work in IE, have serious performance issues and have been deprecated.

Useful Tools

We've found the following tools extremely useful when diagnosing compatibility problems with Websites. Using them can greatly decrease the amount of effort and guesswork that goes into fixing compatibliity issues:

1. Google Chrome has a variety of built-in tools to help developers track down compatibility and performance issues.
2. Firebug - An excellent Firefox extension that can help examining markup, JavaScript and performance issues.
3. Fiddler - A free Windows-only tool that allows you to examine and replay HTTP requests and responses.

Additional Resources

1. Google Chrome Webmaster FAQ - Contains all the information in this document and loads more.
2. quirksmode - Useful Information about which features are implemented in which browser.
3. Reporting a bug in Google Chrome - guidelines and pointers on how to write an effective clear bug report.