Archive for the ‘Web Browsers’ Category

User Agent Switcher XML file update


With help from Gerhard, a QAInsight reader, the User Agent Switcher MONTSTER XML file has been updated to use the new, folder feature. Also, another IPhone user agent has been added as well as one for Chrome. As always, the permalink is here, and can be found in the right navigation under the “My Testing Tools” header, link: “User-Agent Info and Tools“.

Determining browsers’ rendering and JavaScript engine versions


Now that I’ve updated and found a permanent home for the Browser Compatibility Cheat-Sheet, I thought I’d take the time to share the method to my madness for excavating the rendering engine and JavaScript data from browsers (these are the details in the cheat-sheet). If you’re asking yourself “Why do I care Brent?” then I urge you to watch my screencast on Browser Compatibility Testing Risk Analysis. My answer to your question in a nutshell is that you need to care as a developer or tester because fully understanding how browsers work, knowing how similar and different they are, and being able to quickly assess how a feature or change to a Web application will impact your development, testing or regression. I’ll leave it at that for now.

It’s never really been quick or easy when I mine the data (which seems to be about once a year), but when I reassess the cheat-sheet I typically spend most of the time re-reminding myself of how to gather the info for the various browsers, all the while discovering new sources. Here is my high-level browser info excavating process:

  1. Get the info from the browser itself:
    1. Install it
    2. Look at the browser download site, FAQ, & Release Notes
    3. Look at the user-agent string at
    4. Look at the installed assembly version numbers and text files
    5. Look at the Help/About section
    6. Look at comments in source control and source code (if available)
  2. Search the web
    1. Look at keywords on wikipedia (Netscape, V8, WebKit, etc) . Wikipedia has gained a lot of browser data in the last couple years, some of my favorite and most useful links are comparison of layout engines & Browser Timeline
    2. Search by keywords, and look at articles and comments on the Web

And on to a few lower-level details for a few of the most popular browsers:

Internet Explorer

  1. Rendering Engine: Trident being the name of the IE rendering engine, it was once believed that the version of Trident matched the the version of the MSHTML.dll found at C:\windows\System32\. But with IE 8.0, the IE team has a reference on their blog that rendering engine in 8.0 is Trident 4.0 which can now be found in the user-agent string. This version conflicts with prior data I had gathered but we’ll run with it.  Hopefully, from here on out you can just gather the version from the user-agent string, only time will tell. Here is an example user-agent string for IE8: “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;)
  2. JavaScript Engine: JScript is the JavaScript engine in IE, the file version of JScript.dll found in C:\windows\System32\ will give you version number.


  1. Rendering Engine: Webkit is the rendering engine for Chrome. To get the rendering engine version, in the browser URL bar just type “About:”. The version will follow the “Webkit:” key. Notice that the User Agent contains the same Webkit number, hence the rendering engine version can be gathered from the User Agent string also.
  2. JavaScript Engine: V8 is the JavaScript engine for Chrome. The version is listed in the same place as the rendering engine and is the number following the “V8:” key.


  1. Rendering Engine: Firefox uses the Gecko rendering engine and the version number can be found in the user-agent string (can be seen by typing “about:” in the URL bar or going to Help->About in the menu). For example in the following string: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2009042316 Firefox/3.0.10”, the “rv:” is the version and the “2009042316” build number. 
  2. JavaScript Engine: Firefox’s JavaScript engine is SpiderMonkey and I’ve never found references to version numbers. From what I understand the JavaScript engine is compiled to JS3250.dll in \program files\mozilla firefox (js3250.lib on Linux), but the version number never changes on it even though the date and size do, which makes tracking here fairly useless. I’ve always gathered ECMA compatibility data from official release notes as well as using the value for “JavaScriptVer ” key found when visiting (click the ‘more’ link in top-right corner to get this detail).


  1. Rendering Engine: Webkit is the rendering engine in Safari and the version can be found in the user-agent string. For example in the string: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Safari/528.17” the version number is 528.18. This can also be seen on the webkit.dll file property “Product Version” in Windows (\program files\safari\).
  2. JavaScript Engine: With Safari 4.0 and up the JavaScript engine is new and named Nitro. At this time of writing 4.0 is still in beta and I see no official version for Nitro, but hopefully we’ll find a reference once it comes out of beta. Regarding past versions for their old engine JavaScriptCore, I’ve never found version numbers so I only documented the JavaScript ECMA compatibility found at various places on the web as well as the value for “JavaScriptVer ” key found when visiting (click the ‘more’ link in top-right corner to get this detail).


And there you have it, the method to my madness. If you have differing or better data please feel free to add it in a comment.

Browser Compatibility Cheat-Sheet


Browser Compatibility Cheat Sheet This link/post will serve as the official place for the Browser Compatibility Cheat-Sheet and the post can be permanently accessed from the side navigation. Any new updates/links to the cheat-sheet will be put in this post.

What is the Browser Compatibility Cheat-Sheet?

The cheat-sheet is a list of browsers’ rendering engine and JavaScript engine versions. This reference provides testers a quick and easy way to view groupings of browsers and their versions to help determine testing redundancy and trim the “browsers to test” list. For further explanation and details watch the screencast: Browser Compatibility Testing Risk Analysis.

Download the latest Browser Compatibility Cheat-Sheet here (zipped Excel file): (8.74 KB)

iPhone Browser Simulator on Windows


Written over a weekend, Sean Sullivan the CTO of Black Baud lab’s created an iPhone browser simulator, and it’s FREE!

Basically, what he did was take the Webkit rendering engine from Safari and embed it into a Windows application. Browser requests are being made through Safari Webkit using an iPhone mobile user-agent string. Here is an example of the user-agent string that came into my website while capturing the screenshot at the bottom of this post:


Setup is as simple as installing Safari, and then running the .exe from Black Baud lab.

Check out the details and a screencast on Black Baud lab’s site. always, when it comes to browser compatibility testing there is nothing like testing the real browser on the real platform. Keep these things in mind my dear browser compatibility testing friend:

  1. The rendering results will be based on the version of Safari for Windows you have installed and its Webkit version. This will likely not match the version you intend to test on the iPhone. For example, I’ve installed Safari version 3.2.2 which uses Webkit 525.28.1, the page I’m testing will utilize that version. Make sure you are aware of the iPhone browser version you need to be testing and the Webkit version that comes along with that iPhone browser version. You’ll need to install that version of Windows Safari to be in sync with the iPhone.  How do you know which version of Safari/Webkit is running in an iPhone app install? I don’t know! I can find no reference or history of versions on the Web. I suppose it could be gathered easy enough by installing each iPhone app version and then either doing a Help->About in Safari? Or gathering the data from the user agent string by going to Post a link in the comments if you’ve seen this data somewhere. 
  2. Apparently iPhone Safari 3 is not the same code base as Safari 3! The code base was branched. Changes made in that branch could cause your results to vary between the real iPhone browser and the iPhone browser simulator. From the threads I’ve read it seems to be more “shell” type features, which lowers your risk if you’re just looking for rendering issues.


7 Ways to Test Browser Compatibility


Seven ways to test browser compatibility, without having to manage your own testing lab:

Browser compatibility testing solutions have made some progress in the last year but it’s still far from ideal. A while back, I had a dream

  • I want to screen-shot any page in my website (requires a decent, free, scripting engine that will allow me to get to the various pages in my site that can’t be accessed via a specific URL (Watir?) ).
  • I want to screen-shot my site that is not yet published for the world (requires the service to exist within my internal network).
  • Once I’ve approved an ideal layout screen-shot I want the software to determine and tell me if the other screen-shots are worth looking at (by doing a statistical image comparison with a predefined pass/fail threshold).  Maybe MeerMeer is on the right road to doing this?
  • I want to provide basic wire-frame definitions and have software determine if my screen-shots are within reason (by analyzing elements in the DOM and browser dimensions)
  • Get rid of screen-shots and do DOM to DOM element width and height comparisons between browsers (Come on, it’s a dream, standards compliance for all browsers (another dream) might make it possible?)

How to View JavaScript Errors in Google Chrome


In the slim and clean Google Chrome (beta) interface JavaScript issues are not easily detectable unless your page or site is visually broken. Much like FireFox and Safari, a tester must open the “JavaScript console” and keep it in visible view while they test in order to catch JavaScript errors. Chrome’s Javascript console is a lot like Safari’s, but is a tad worse (see the gotchas at the bottom of this post).

My fellow testers, here is how to get to that JavaScript console and monitor for JavaScript errors while you test:

Click the page icon to the right of the URL bar. Select “Developer” and then “JavaScript console” from the menu:


In the top of the JavaScript console window click the “Resources” button:


Start testing. When an error occurs you’ll see a red icon with a number in it next to the page that the error occurs:


You’ll also see a log of the error in the bottom of the JavaScript console window, if you click the provided link it will take you to the line of code where the error occurs:


Also, if you click the page in the “Resources” section the offending line of JavaScript and the error will be displayed:


As of now, I see two gotchas in Google Chrome Beta when attempting to detect/find JavaScript errors:

  1. The “JavaScript Console” reports more than JavaScript issues which makes sorting/distinguishing JavaScript errors from other reported HTML style of formatting errors tough. A cheesy visual helper is to also open up the “Debug JavaScript” window (found in the same Page > Developer menu to the right of the URL bar) and watch for new line items to show up in the log. Those line entries are associated with JavaScript errors, unless..
  2. You changes sites/domain, in this case the previously opened JavaScript windows won’t display data for the new site. You have to close those instances and re-open them to monitor the new site.  You know that the monitoring has stopped when you see in the “Debug JavaScript” window the following log entry: “lost connection to tab”

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, 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:


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.

I added IE 8 to the user agent switcher import file



The IE team announced what the user agent string for IE 8 will be:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

This particular one is for Vista. They’ve decided not to use the ‘b’ in ‘MSIE 8.0b’ for the beta version this time due to issues they’ve encountered in the past with that approach. I’ve updated my User Agent Switcher import file to contain the string for Internet Explorer 8 on Vista and XP. As always you can get to that file from the right menu under the “My Testing Tools” section: User-Agent Information and Tools. Load up the new file and go see if your browser detection script will work with IE’s new string.

I also updated it with FireFox 2.0.12 for Vista.

Browser Compatibility Testing Risk Analysis


I did my first presentation for the Phoenix Software Quality Association (PSQA) yesterday evening on “Browser Compatibility Testing Risk Analysis”. Those who attended learned:

“The art of trimming browsers from a browser compatibility test list by knowing your users, understanding how the browser works, OS & browser facts versus misconceptions, and grouping browsers by common component versions to remove redundancy.”

For those that attended I promised to post my presentation and handouts here on my blog. So here they are:

Packaged Download
Browser Compat (1.62 MB)

Individual Downloads
Browser Compatibility Testing.pptx (1.65 MB)
Browser Facts Misconceptions and Experience.docx (29.24 KB)
BrowserCompatCheatSheet.xlsx (14.89 KB)

Setting Browser Compatibility Testing Expectations.docx (13.87 KB)

If you don’t have Office 2007 you can get the Office 2007 viewers here for free.

I’m thinking about screencasting this while it’s fresh in my mind. If I do, it will be posted here within the next few weeks.

PSQA is always looking for presenters or a place to meet. If you can offer up either, the organization would greatly appreciate it (contact If you’re in the valley, have anything to do with QA, and are not already a PSQA member, go sign up. It’s free!

More on Standards Compliance in Internet Explorer 8



After the IE Team posted their intent and work on compliance to standards the debates have begun. Revelations have shown that the standards compliance is really an an option that would be invoked by a developer with a META tag or header using the value of  ‘X-UA-Compatible’. Now, IE 8 will have 3 modes:

  1. “Quirks mode” remains the same, and compatible with current content.
  2. “Standards mode” remains the same as IE7, and compatible with current content.
  3. If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element. Aaron gives more details on this in his article.

There is much debate on how this will impact the Web, user experience, as well as how developers will program. There are interesting thoughts around all of them. What is most intriguing to me is that IE 8 is going to be standards compatible. With news like this, I can now test that a Web application conforms to a standard. The standard is now my guideline for my set of test cases. But really will it be a “set of test cases”? Quite possibly it could be only one: Load the page and validate that the page is rendered using “Best standards mode”. But hopefully the test wouldn’t even be of my concern, with the right Content Management System, the code will be compiled by a developer and the check will be done by the CMS before release to QA. Either way, conforming to standard lowers the risk of a browser compatibility dramatically.

Another interesting feature in IE 8 is the idea of “Version Targeting”. In other words

“The idea is that when IE10 loads up my IE7 page, it rewinds itself to act like IE7 did, all those years ago—no matter what changed in the meantime.”

What will “Version Targeting”, do to my browser compatibility testing list when IE 8 is released? My first impression is that it won’t slim my test list at all. For example, if you have a page that is coded for IE 8 and X-UA-Compatible, it doesn’t necessarily mean that it will look good in IE 7 or in IE 6 since the code is targeted for IE 8. Using that same Web page (IE 8 and X-UA-Compatible), will the testing list shrink with the release of IE 9? It depends… Will the standards and the compliance to those standards change between IE 8 & 9? How many compliance to standard defects were in IE 8 and fixed in IE 9. If their were few defects and the standards didn’t change then the risk is low and you probably wouldn’t need to test both IE 8 and 9, just 9.

It’s too early to speculate and come up with concrete answers. The IE Team is still working through this stuff with themselves and the active community. But I’m happy to see their attention on the matter.

Post navigation