Google Gives Us Another Browser to Test: Chrome

image Just when you thought you had a handle on your browser compatibility testing, Google gives us Chrome.  What does that mean for you, the infamous browser compatibility tester? Just another browser to test? Yes and no…


Have you seen my previous screencast on Browser Compatibility Testing Risk Analysis? If not, its a worthy watch if you want to get a feel for how the browser generally works and how to trim that browser test list based on a little bit of data and risk analysis. Once that’s under your belt, continue on my friend…


Let’s dive into the details of Chrome to get a quick grasp on where some new browser compatibility defects for your site may be lurking:


The Layout Engine
What does Google Chrome use for a layout engine? WebKit. The same layout engine that Safari uses. Will it render exactly like Safari? Well, it depends on which version of WebKit that  your installations of Chrome and Safari use. You can determine this quickly by looking at the user-agent string. A quick way to do this is to go to BrowserHawk.com, click “more” in the top right menu, scroll to the bottom of the new page and look for the text “User agent”. Here is the Google Chrome user-agent:


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


As you can see we have a WebKit version of 525.13. Chances are that the latest version of Safari runs WebKit 525 also (again do this by looking at the user-agent of the latest version of Safari). Ignoring the minor version number and focusing on the major version number, if they are the same we can feel comfortable that Chrome and Safari will display layout the same…Meaning they will align objects on the page the same. If you’ve already tested Safari, chances are you aren’t going to find any unique layout defects in Chrome.


The JavaScript Engine
This is where things start to get different. In Google Chrome we have a brand new engine and way of doing JavaScript. Google calls their new engine V8. Safari’s engine is JavaScriptCore. Night and day…expect to see differences and potential issues here. When testing make sure to look for JavaScript errors and possible issues with sites that us AJAX (in my next post I’ll talk about how to view JavaScript errors in Chrome) .


The Shell
What stands out the most to me in Chrome’s “shell” is the fact that tabs, plug-ins, and JavaScript run under there own process. On the surface this looks like an ideal way to manage security and to keep memory in-check, but I would keep an eye on functionality of pop-ups and session management between windows (as in, losing reference where there needs to be reference). Also, notice the clean-cut/different “shell” that Chrome has… This “shell” could also yield potential defects related to printing, or any other page related features that you may find in the various menu bars/icons or “Options” menu.



In summary, if you are asked to test both Safari and Chrome the layout is going to be the same (if the WebKit versions are the same). However JavaScript and the Shell could yield some unique defects.

Leave a Reply

Your email address will not be published. Required fields are marked *