Posts in Category "Technical Info"

Testing Private Content with BrowserLab

Testing Private or Local content in BrowserLab

A recurring question we get on the BrowserLab User Forums is “How can I test pages that I have on my local machine and/or behind my firewall?”

A public URL is normally necessary because BrowserLab generates screen shots by visiting the page and taking snapshots of it in the actual browser. There are, however, three alternative methods for using BrowserLab that will allow you to test pages that are not publicly available.

BrowserLab for Firebug

The most versatile option is to use the BrowserLab for Firebug add-on for Firefox. Currently the BrowserLab for Firebug add-on supports Firefox versions 3.x to 6.x and will be extended as new versions of Firefox are released. For our add-on to work, you must have the correct versions of Firefox, our add-on and Firebug installed. Fortunately, Firefox does a really good job of helping you stay current and in sync.

The BrowserLab for Firebug add-on allows you to test private content by selecting the “Preview Local Source” option from the BrowserLab for Firebug menu in Firefox. You can also test publicly available content by selecting “Preview URL,” which simply sends the current URL to BrowserLab. When you choose the “Preview Local Source” option the add-on uploads the HTML content and assets from your machine to a private directory on Adobe’s servers, which only BrowserLab has access to. Once the files are uploaded, BrowserLab can take screen shots from that secure server. Please note, you must select the Options menu item and ensure that the read-only permission option has been set to “Allow.” You are able to test private websites and intranet pages by first navigating to the page in your browser and entering any username/passwords, once you choose “Preview Local Source” the local content from your browser is uploaded and screen shots are generated.

For more information on the precautions taken to ensure content uploaded to Adobe’s secure server for screen shots is inaccessible to any other user, please read our tech note.

Because the page is running in your Firefox browser, this also allows for some limited interactive testing of your pages. For example, if you have dynamic menus, dropdowns or similar elements on your page, you can select the “Freeze JavaScript” option, interact with your page to display those elements, and then request screen shots of the page in that state either by selecting the “Preview Local Source” menu option or pressing the hotkey combination for it (Ctrl-Shift-F12 in Windows, Command-Shift-F12 on Mac OS X)).

When using Preview Local Source, another option to be aware of is the “Preserve CSS Hacks” setting. When a website uses a browser-specific CSS hack that Firefox doesn’t recognize, it is stripped out of the final page displayed in Firefox. Since “Preview Local Source” uploads the content that is currently in your browser, it can cause previews of the page in other browsers to display incorrectly if non-Firefox hacks specific to those browsers were removed. The “Preserve CSS Hacks” can fix this by merging those missing hacks back into the content that is uploaded to our servers for testing.

Please note, the purpose of this post isn’t to cover every possible situation you can run into, but if you’re having problems getting “Preview Local Source” to work correctly, make sure to check the “Freeze JavaScript” and “Preserve CSS Hacks” options, and try bumping up the screen shot Delay setting to allow more time for the page to finish loading before screen shots are captured.

If you’d like to see all of this in action, watch our BrowserLab for Firebug video on AdobeTV.

BrowserLab for Dreamweaver

If you use Dreamweaver CS5 or CS5.5 you can test private content using the BrowserLab for Dreamweaver extension, which is included in the product.

To begin, you should first ensure that you have the most up-to-date version of Dreamweaver by choosing Help > Updates from the menu and installing any available updates. Once you have finished updating (and restarting your computer if needed), open the BrowserLab panel by choosing Window > Extensions > Adobe BrowserLab from the Dreamweaver menu. You can use the dropdown control in the panel to switch between testing private (“Local/Network”) content and public (“Server”) content. This blog post will only focus on testing private content.

The extension allows you to test private content by creating a secure tunnel between your network and a private directory on Adobe’s servers, which only BrowserLab can access and take screen shots from. (See Data Privacy Concerns, above, for more information about how your data is kept private.) For this to function properly you should have a site set up within Dreamweaver (Site > Manage Sites) with the Local Site Folder field pointing to the root of your local site. Next, in the BrowserLab panel, select the list icon to open the extension menu, choose “Permission Settings”, and make sure the Allow option is selected. These two settings allow the BrowserLab for Dreamweaver extension to know the location of your pages and related assets, and will permit it to upload them to Adobe’s servers.

We’ve taken every precaution to keep your data safe, secure, and inaccessible from any other user. If you are still concerned about the security of your files when uploading them to BrowserLab, please take a look at our tech note on this subject.

Once you’ve followed these steps, activate the site you want to test in Dreamweaver by selecting it from the Sites menu in the Files panel. When the page you want to test is displayed, select the Preview button in the BrowserLab panel. Your page and all necessary assets will be uploaded to our servers, BrowserLab will open in your default browser, and screen shots will be returned (you’ll be asked to log in if BrowserLab was not running already). In addition to allowing you to test your local pages, this integration allows you to test interactive states of the page such as rollovers and tabs by switching to Live View in Dreamweaver, interacting with your page, choosing Freeze JavaScript to freeze the page state, and then clicking the Preview button in the BrowserLab panel to generate screen shots for that state in all your selected browsers.

If you’d like to see BrowserLab for Dreamweaver in action, watch our BrowserLab for Dreamweaver video on AdobeTV.

Allow BrowserLab Egress IP access

The final option for testing private content with BrowserLab is simply to allow BrowserLab to direct access to your content by granting permission to BrowserLab’s egress IP addresses. You can find more details in our blog post covering this topic. To reiterate our warning from that post – If you have confidential information then it may be best not to use this method for testing secure content, or to only allow our IP addresses access while you are actively testing. The primary reason for port forwarding would be if you have a webserver at home or in a small office and don’t have access to a staging server on the Internet. In most cases, this should not be done unless you know what you are doing.


BrowserLab is a versatile and easy to use testing tool to help you achieve cross-browser consistency and can be used with private, local and public content. It is fast and secure, and takes the hassle out of cross browser testing. Once you start using it, you might wonder how you ever got along without it.

Mark Rausch
BrowserLab Engineer

Why Does My Page Look Different In BrowserLab?

Does Your Page Look Different In BrowserLab?

In a recent blog post we covered some reasons why you might see rendering inconsistencies in BrowserLab when looking at screenshots from Internet Explorer 9.  Now let’s take a look at why you might see some cross-browser testing differences between the way BrowserLab’s screenshots display your page versus how your page looks on a local machine.  If you’ve run into a situation where the screenshot from BrowserLab doesn’t square up with what you see locally in the exact same browser, there are a few known culprits.

Resource Availability

If you’re seeing major rendering differences, such as missing images or stylesheets, make sure that the resources you are referencing in your page are available to BrowserLab.  Start by increasing the Delay setting in BrowserLab, to give the resources a little more time to load. Make sure you aren’t referencing resources that you have installed locally or are only visible from inside your network.  If you are in doubt, ask a friend who is outside your own network to take a look at your page.  If your friend can’t see the missing resources, BrowserLab won’t be able to either.  If you need BrowserLab to be able to see content inside your network, you may want to take a look at this article about Egress IPs or use one of our options for testing local content.

Screen Resolution

The screenshots you get back from BrowserLab have all been rendered on browsers sized to 1024×768. If you are looking at the page on a browser that’s sized either larger or smaller, you could see some layout differences.  Try resizing your browser to 1024×768 and reload.  The very popular Web Developer add-on for Firefox has a tool to do this easily.

Browser Chrome

This one is really an extension of the same problem described above.  If you have installed any toolbars (like the Web Developer add-on suggested above), or if you are using a browser theme that changes the size of the borders, buttons and other chrome around the browser, you may get slight changes in window size, which could make the screenshot look different.  You’re most likely to run into this if you have multiple toolbars installed and are seeing vertical sizing or spacing issues.

Different or Missing Fonts

We try to keep our browsers as close to their default installation as possible.  This also means we have not installed any fonts beyond what ships with the OS.  If you are seeing font discrepancies, this may be behind them.  Consider using Web Fonts, as described in a previous blog post.

Browser and/or System Settings

If you have changed certain default settings on any of your browsers or in your OS, then it’s possible that you may run into subtle rendering differences.  A good example of this is the ClearType font smoothing setting in Windows.  If you’ve turned off font smoothing on Windows, you may see some differences in font rendering.  But more generally, remember one of our main philosophies: to try and keep our browsers as close to a default install as possible.

Operating System Differences

Remember that font smoothing issue from above?  ClearType font smoothing is on by default in Windows XP and higher, but not in Windows 2003.   It’s not practical for us to serve screenshots from every permutation of the various browsers and operating systems that are available.  We’ve tried to provide an experience that represents what a typical user may have installed, but you may find small rendering differences between OS versions, and even OS patch levels.


If you are seeing screenshot discrepancies that cannot be explained by any of the above causes, we’d love to hear about them!  Consider coming over to the BrowserLab User Forum and letting us know about the problem you’re seeing.

Duane O’Brien
BrowserLab Engineer

IE 9 and Compatibility View

BrowserLab and Internet Explorer 9

Are you seeing IE9 rendering inconsistencies in BrowserLab?

Since we’ve added support for Internet Explorer 9 to BrowserLab, some users have been asking why BrowserLab shows a different rendering result than they see when testing locally with a real IE9 instance. Most of these differences end up being rooted in the same issue: IE9’s Compatibility View List.

Microsoft’s IE9 Compatibility View List contains a list of websites, which Microsoft believes are best displayed in a mode other than IE9 Standards mode. When viewing a site, IE9 will check whether the site is on the Compatibility View List, and if it is, the site will be displayed using Compatibility View – usually as if it were IE7.  If the site is not on the list, it will be displayed in IE9 mode, and the rendering mode will be determined based on any meta tags and the DOCTYPE.

As mentioned previously on this blog, our philosophy for BrowserLab is to provide browsers that are as close to the default installation settings as possible. Most people do not change their browser settings, so the browsers in BrowserLab are most likely to reflect the installed base of browsers. Compatibility View List is on by default in IE9, so we’ve left it on for the IE9 browsers in BrowserLab.  Some web pros have turned off Compatibility View in their local IE9 installation, which can cause a different rendering result.

IE9 Standards and Compatibility modes, side by side

IE9 Standards and Compatibility modes, side by side

For example, it is pretty common for web pros to temporarily host their sites on Dropbox, allowing simple synchronization and the ability to easily share with clients, etc. Unfortunately, is on Microsoft’s Compatibility View List, which causes all content from the domain to be rendered in IE7 mode.

Assuming that the final host of the content is not intended to be Dropbox, BrowserLab may end up providing a false negative (though if a client previews the content from with IE9 they may also see it rendered in IE7 mode). The BrowserLab team believes this to be preferable to the alternative where we turn off the Compatibility View List and run the risk of providing a false positive where BrowserLab shows you that the site renders correctly in IE9, but the majority of users with Compatibility View List turned on will see it in IE7 mode.

What Can You Do?

If you notice a discrepancy between your local IE9 browser and BrowserLab, there are some things you can do to identify and fix/work around the issue.

Start by determining whether the difference in rendering is due to IE9’s Compatibility View.

Verify whether Tools > Compatibility View Settings > Include updated website lists from Microsoft is checked in IE9. If this is checked, you have Compatibility View turned on and your results should match those from BrowserLab.  If your results do not match BrowserLab, please let us know of the issue by posting on the BrowserLab User Forum.

If Include updated website lists from Microsoft is unchecked, you can either enable it to see if IE9 then renders it differently or you can manually check whether your domain is on Microsoft’s Compatibility View List.  If your domain is on the list then it will not, by default, render in IE9 Standards mode.

To force IE9 to render in IE9 Standards mode despite the Compatibility View List, you can add either of the following X-UA-Compatible meta tags to your HTML:

Render page in IE9 Standards mode, ignore doctype: <meta http-equiv="X-UA-Compatible" content="IE=9">

Render page in IE9 mode assuming a standards-based doctype, IE5 (quirks) mode otherwise: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">

Alternatively, if you control the domain on which you are previewing the page and don’t think it should be on Microsoft’s Compatibility View List; you can contact Microsoft to address this.


Tell us what we can do to make this experience better for you.  Do you need to see IE9 results with Compatibility View explicitly off as well as on?  Should we somehow display the document mode that BrowserLab’s IE9 browsers are actually rendering in?

In a future blog post, we’ll talk about other factors that might affect rendering consistency and cause you to see different results between BrowserLab and your local browsers, and ways to minimize them.

Matt Johnson
BrowserLab Engineer


Understanding the Compatibility View List:
Current Compatibility View List:

BrowserLab for Dreamweaver

When the Creative Suite and Dreamweaver CS 5.5 shipped earlier this month, I was invited to write a guest blog post on the Dreamweaver Team Blog. I wrote about the improvements the team made to the BrowserLab for Dreamweaver extension and workflow, as well as some of the new features. If you’re a Dreamweaver user, we hope you enjoy the improved workflows.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab Egress IP Addresses

The current public egress IP address for the BrowserLab service is:

(Updated August 28, 2012)

These addresses are subject to change, but we will try to keep this blog post updated with the latest changes.

What are the egress IP addresses and why should you care? When you ask BrowserLab to return screen shots for a url, our servers will make the request from one of these two addresses. Users of BrowserLab can take advantage of this information in a few different ways:

First, since a single test run from BrowserLab could result in almost 20 visits to the page, you might decide you want to exclude BrowserLab visits from your site analytics. Most analytics tools will allow you to list individual IP addresses or a range of addresses to ignore.  Here are some examples for Google Analytics and WebTrends.

Second, since BrowserLab will make so many simultaneous requests for your page, it can sometimes be mistaken as an attack by some pieces of hardware or software. To avoid this, you can put our egress IP addresses in as trusted IP addresses that can safely be ignored.

Third, you can use the IP addresses to exempt BrowserLab from some types of password protection you can set up for your web pages. For example, you can use the htaccess configuration file in Apache to password protect a site from the general public, but configure the htaccess to allow BrowserLab access without a password.

Finally, you can use the IP addresses to allow BrowserLab to reach through your firewall to get screen shots for pages it couldn’t otherwise get to. Port forwarding allows you to access a machine behind the Firewall at a specified port. For instance you could have your firewall  direct public traffic on port yourIP:9999 to port 80 on an internal webserver. By limiting access to the BrowserLab servers, you are limiting the exposure to the outside world. The risk in doing this is that another BrowserLab user could guess that you’ve done this and submit URLs that they think are internal to your network. If they guess correctly, they will get screen shots of the pages that they correctly guess. The other risk is that you do something wrong and open an internal machine to the internet. If you have confidential information then it would be best not to use this method for testing secure content or to only allow our IP addresses access while you are actively testing. The primary reason for port forwarding would be if you have a webserver at home or in a small office and don’t have access to a staging server on the internet. In most cases, this should not be done unless you know what you are doing.

If you want BrowserLab to be able to access your pages behind a firewall, we recommend that you either talk to a knowledgeable person in your IT department or, if you are without an IT department, here are some links with instructions on how to set up port forwarding for some of the more common routers: Netgear informationLinksys information.

A full discussion about port forwarding is outside the scope of this blog post since the process can vary widely from router to router. It can help to have a friend from outside your network try and access the content you want to test (just make sure to add their IP address to your whitelist). If your friend can’t get to your content, the BrowserLab servers won’t be able to either. If you find yourself having difficulty getting it to work, your best bet is to consult the documentation for your own hardware or contact a qualified IT support person.

As I said above, these egress IPs are occasionally subject to change. We’ll do our best to keep this post updated with the latest IPs and are also considering ways to make finding the current ones more convenient. For now, if you want to ensure you have the correct IP address, you can determine that by submitting as a URL to BrowserLab. The returned screenshot will show our current egress IP.

Mark Rausch
BrowserLab Software Developer

Release 1.5.3 adds Chrome 10, IE 9 & Firefox 4 RC

BrowserLab 1.5.3 is now live!

As part of our ongoing efforts to keep the browsers in BrowserLab current and relevant, we’ve released BrowserLab v1.5.3 today.  This release added Chrome 9 and 10 (Windows), Internet Explorer 9, and Firefox 4 RC (Windows). In addition, we’ve updated Safari to 5.0.4 (OS X).

When we do these kinds of releases, we also update our browser servers to include the latest system updates and security patches. The other notable change we made was to enable Font Smoothing on our Windows Server 2003 browser servers – now all of our browser servers have Font Smoothing enabled.

Tell a friend about BrowserLab! We need your help to raise awareness. In addition to this blog, there are a few ways to stay in touch with us:
Twitter: @adobebrowserlab, @brucebowman
BrowserLab User Forums:

Next up: we’re working on more browser updates for OS X, as well as an update for our BrowserLab for Firebug extension so it will work with Firebug 1.7. You can expect these changes to come soon.

We’d love to hear from you in the comments!

Bruce Bowman
Adobe BrowserLab product manager

Using Web Fonts with BrowserLab

Before wide browser support for the CSS @font-face rule, web pages were limited to “browser safe fonts.” This meant the designer was constrained to using fonts that were available on every visitor’s machine. @font-face allows a web designer to make typeface decisions based on aesthetics rather than availability.

All modern browsers now support web fonts, in some form. Microsoft Internet Explorer has supported @font-face since 1997 in version 4, Apple Safari implemented support in 2008 in version 3.1, Mozilla Firefox added support in 2009 in version 3.5, and Google Chrome added support in 2010 in version 6.

Adobe BrowserLab has full support for @font-face. BrowserLab can help you ensure your @font-face declarations are working across multiple browsers. By giving you the ability to quickly test your @font-face declaration across target browsers, you can move on to designing the rest of your site. Give BrowserLab a try with your web fonts enabled pages.

When using @font-face you need to be aware of supported font formats and browser specific syntax.  There is currently no universally supported web font format. Failing to provide proper font formats and browser supported CSS will result in your page rendering inconsistently across browsers.  If done incorrectly, visitors will see the browser’s default font instead of the specified font.

There are some great font services that take care of cross browser support by dynamically generating the appropriate CSS for each browser. Typekit, Webtype, WebINK, and are some of the services available, and all of them generally take care of hosting and licensing. Using one of these services allows the quickest path to implementation without having to know too much about the underlying technology. Typekit provides many fonts created by Adobe, and we are working together to offer more Adobe fonts in the future.

If you find yourself needing to roll your own web fonts, there are a few basics that are required to ensure your intended fonts show up on all browsers:

First, and most importantly: Ensure your font license allows you to use a font on the web. Many foundries do not permit the use of their desktop fonts on the web. For more information, check out the Adobe Type blog on this subject.

Know your font formats. There are a few different versions of web fonts in use today.

  • Embedded OpenType (.eot) – Supported by Internet Explorer only.
  • TrueType/OpenType (.ttf/.otf) – Supported by the widest range of browsers, but, not supported in Internet Explorer. (this may change in IE9)
  • Web Open Font Format  (.woff) – Supported in recent versions of Chrome, Firefox and Internet Explorer, but not yet supported in Safari.

In addition to needing to worry about licenses and multiple font formats, browsers interpret CSS code differently, so writing a rule to include your fonts is less than straightforward. “Bulletproof” syntax for @font-face has evolved over the years to work around browser inconsistencies. Much of the syntax seems repetitive and counter intuitive. For a good history of @font-face and a clear explanation of the CSS syntax read the “The New Bulletproof @Font-Face Syntax” blog post at Fontspring. Learning how the syntax has evolved gives a clearer picture of how each browser handles @font-face.

FontSquirrel is a web service that will convert fonts for you and generate CSS code.  After uploading your fonts, FontSquirrel will convert your fonts for cross browser usage and generate CSS for you. The CSS code generated by FontSquirrel also happens to work just about everywhere, including mobile devices. If you use FontSquirrel to generate web fonts, make sure you have the proper license to do so.

I hope this brief introduction to web fonts has been helpful, and that you find BrowserLab to be a useful tool in helping you test your pages with web fonts.

Shout out to Paul Irish, Christopher Slye on the Adobe Type team, and Fontspring for their help and insight on web fonts.

Charlie Scheinost
Adobe BrowserLab Software Engineer

BrowserLab and User Agent Strings

When visiting a web site, your browser provides a number of details about your system and browser version to the web servers via a user agent string. This information can be used by the web site to, among other things, provide browser specific content to you. The user agent string generally looks something like this:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv1.9.2) Gecko/20100115 Firefox/3.6

See What is a User Agent for a more detailed look at the individual components of the user agent string.

User Agents in BrowserLab

Most browsers have a single user agent string that they send based on the browser version and operating system. Additionally, the general policy within the BrowserLab service is to run the browsers in their default install states so as to best match the median user’s installation. This means that BrowserLab screenshots for most browsers will report the standard user agent.

However, both Internet Explorer 8 and Internet Explorer 9 Beta include a ‘Compatibility View’ that will force the browser to report the Internet Explorer 7 user agent string and subsequently render the page as Internet Explorer 7 would.

Internet Explorer 7 user agent
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322)

While Compatibility View is, by default, off in Internet Explorer 8, it may be enabled by default when you install Internet Explorer 9 Beta. For BrowserLab screenshots we explicity force Compatibility View to be off in both of these browsers, ensuring that these browsers receive and render content meant for Internet Explorer 8 and 9 Beta. The user agent strings that these browsers then send are:

Internet Explorer 8 user agent (Native)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident 4.0; .NET CLR 1.1.4322)

Internet Exporer 9 Beta user agent (Native)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Would support for Compatibility View in Internet Explorer 8/9 Beta be useful to you within BrowserLab or is the equivalent rendering provided by Internet Explorer 7 sufficient? Is there other functionality related to user agent handling that you would like to see in BrowserLab?

Related Resources

Matthew Johnson
Adobe BrowserLab Software Engineer

BrowserLab for Firebug – compatibility with Firebug 1.6

Update Dec 11, 2010: We’ve updated our BrowserLab for Firebug extension to version, which is now compatible with Firebug 1.6. You can update to the new version in Firefox by choosing Tools > Add-ons, switching to the Extension tab, then clicking the Find Updates button. You should see the new BrowserLab for Firebug v1.0.0.867P.265076 in the list of updates. If you don’t, you can get the new version manually by going to the Mozilla Exchange.

For those of you using our BrowserLab for Firebug extension, we wanted to let you know that it is not compatible with Firebug 1.6, which released today. We’re in the process of testing a new version of our extension to work with Firebug 1.6, and will push it to the Mozilla Exchange as soon as possible. In the mean time, if you want to avoid the incompatibility, you might want to delay updating to Firebug 1.6. We’ll update this blog and tweet when we have a new version of our extension. We don’t expect the wait to be long.

Update Dec 2, 2010: If you’re in a hurry to use BrowserLab for Firebug with Firebug 1.6, you can follow a few easy steps to make it work again. Check out this tech note: and follow the instructions.

When new versions of Firebug or Firefox are released, incompatibilities may be created that keep our BrowserLab for Firebug extension from working until it is updated. Although this is not unusual with Firefox extensions, we’re going to try to anticipate these changes so we can provide you with new versions of our BrowserLab for Firebug extension as quickly as possible. Fortunately, Firefox has an excellent update mechanism that will notify you automatically when there are new versions. If the BrowserLab for Firebug extension is a critical part of your workflow, you might want to consider waiting to update Firebug until you also see an update to our extension.

The upcoming Firefox 4 requires a new version of Firebug, version 1.7. We are working on a new version of our BrowserLab for Firebug extension for Firebug 1.7, and expect to release it as close as possible to the final release of Firefox 4 and Firebug 1.7 – which are expected to be released in early 2011.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

On Browser support, and some coming changes

Within the next few weeks, we’re going to be making several changes to the browsers we support in BrowserLab.

In our next release, coming in December 2010, we’re going to be adding support for 3 new browsers:

  • Firefox 4 beta (Windows)
  • Internet Explorer 9 beta (Windows)
  • Google Chrome 7 (Windows)

Update December 2, 2010: BrowserLab 1.5.2 is now live, and contains the above browsers.

We’re also going to be removing some older browsers:

  • Firefox 2 (OS X)
  • Firefox 2 (Windows)
  • Safari 3 (OS X)

These changes are pretty significant and represent a couple of firsts for us. It will be the first time we’ve removed any older browsers. And it is also the first time that we’ve ever added support for beta versions of new browsers. Going forward, we intend to bring newer, relevant browsers to you sooner than we have in the past. And of course, once the browsers are no longer beta, we’ll be updating them to the shipping version as soon as we can.

Our BrowserLab browsers all have the Adobe Flash Player installed, and otherwise are left in their default factory install configurations. We believe that this is the way most users run their browsers, and will provide you with a testing environment that is most likely to simulate real world situations. If you ever need to know the exact version of the browsers we’re running, in the BrowserLab client, choose Help > About to see version information for our Client, the Flash Player, and each browser.

To help us make decisions on when and whether we add support for a browser, there are several factors that come into play. We look at several statistical sources to gauge market share/usage of browsers. In some cases we also reach out to the browser vendors and make attempts to work with them to provide the best experience in BrowserLab. And of course we balance these with the other priorities for how we invest our engineers’ time in the product.

In addition to the new browsers listed above, we are working on some additional new browser support, and plan to deliver another new release early in 2011.

Do you have questions about our browsers? Go ahead and ask in the comments, and we’ll do our best to provide answers.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman