BrowserLab is shutting down on March 13, 2013

Dear BrowserLab customers,

When we originally launched BrowserLab as a free service back in 2009, our customers were struggling with testing their web content across desktop browsers and platforms. Since then with the growth of the importance of mobile devices and tablets, the landscape has changed dramatically. Because of this shift, we have seen the usage of BrowserLab drop over the past year while at the same time our engineering team has been focusing on solving this new challenge with new solutions. Due to this, we will be shutting down the Adobe BrowserLab Service effective immediately.

If you need to test across multiple desktop browsers, we recommend that you check out BrowserStack and Sauce Labs as two viable alternatives to BrowserLab. Our friends at Sauce Labs are welcoming BrowserLab users with a special offer:

  • 10 hours (600 minutes) of free manual testing time (with no expiration) for up to two concurrent open browsers
  • Once you’ve used those 600 minutes, your account will revert to a free account which includes 30 minutes per month of free manual browser testing
  • This limited time offer will remain valid for 30 days from the date of this blog post

If you are working on mobile web projects, check out Adobe Edge Inspect. It is designed to work on your computer to remotely control actual devices and will allow you to debug web pages directly on a mobile device or phone.

We’d like to thank all of our customers over the years for using and providing input for the Adobe BrowserLab Service.

Best Regards,
Bruce Bowman
Sr. Product Manager, Edge Tools & Services and the Adobe BrowserLab Team

BrowserLab update removes IE7

Internet Explorer 7 has been retired from BrowserLab

Today we have pushed a minor new version of BrowserLab that no longer contains Internet Explorer 7. If you still need to test for IE7 in BrowserLab, you can do this using IE8 and a by adding bit of code to your page(s). To learn more about IE8’s Compatibility Mode, you can read about it in these Microsoft Blogs:

Introducing Compatibility View
Understanding Compatibility Modes in Internet Explorer 8

Remember to remove that code once your testing is complete, unless you want your IE8 visitors to see your page as they would in IE7.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

Adieu, au revoir, ciao, and adios to IE6

We’re (finally) removing Internet Explorer 6 from BrowserLab. Fortunately, we don’t need to include it in the set of browsers any more due to its final decline of usage. We’ve all been waiting for this day.

I wish I could say that we’re removing IE6 exclusively due to its utter and complete lack of relevance. While that’s mostly true, the fact of the matter is that we have an issue with continuing to support IE6, that in combination with its decline of use, made it an easy decision to terminate it. And, I must admit, it feels pretty good to have the last word in this long, painful, protracted battle.

So, IE6, I say to you – You’re out of my life for good. Adieu, au revoir, ciao, adios, sayonara! Good riddance. I will not miss you.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab adds Chrome 18 support

BrowserLab v1.6.6 is now live, and contains the following changes:

  • Chrome 18 support (Windows)
  • New login screen

If you have any problems logging in to BrowserLab, please clear your cache and restart your browser, then try again. We made some significant changes to the login mechanism, so this step may be necessary.

We will update BrowserLab again soon to add the latest Flash Player, and a newer version of Firefox.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab Pricing and Roadmap Announcements

Today we’re pleased to announce that BrowserLab will continue to be free/complimentary, and will not become a paid service in April 2012 as we had previously communicated.

BrowserLab is no longer part of Adobe CS Live. BrowserLab will continue to be available as you use it today, and we do not expect any interruptions in service. We will continue to make updates to BrowserLab, to add new versions of our Browsers, and to keep the service running smoothly and securely.

You may have noticed that the team has been pretty quiet lately, and updates to the BrowserLab service have slowed down over the last few months. This is because the BrowserLab team has been busy working on a new project (UPDATE: Read about Adobe Shadow on the Shadow Team Blog), which will be a nice companion tool to BrowserLab. We think most BrowserLab users will be very interested in the new product, and we’re excited to share it with you. We’re going to unveil it soon, and the first public showing will be on March 12, 2012 at the SxSW Interactive conference in Austin, TX.

If you’re going to SxSW this year, or interested in knowing what we’re doing there , please follow us on twitter @AdobeSxSW.
Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab 1.6.4 with new Chrome and Firefox browsers is now live

Today we have released a new version of BrowserLab for you, v1211P.312309, with updated browsers, security patches and some minor improvements:

  • Chrome 14 was added (Windows), and Chrome 11 was removed
  • Firefox 7 was added (Mac OS X and Windows), and Firefox 4 was removed
  • Safari was updated to 5.1 (Mac OS X)
  • Flash Player was updated to (Mac OS X and Windows)

We will include Flash Player 11 in our next update.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

MAX 2011 in Los Angeles

Today we’re headed to Adobe MAX in LA, excited about all the announcements and the opportunity to meet with our customers and partners. The BrowserLab team will be there, and well represented by me, our designer Matt Hamlin, and engineers Charlie Scheinost and Amit Kishnani. We hope to meet you at one of the following sessions:

Monday, Oct 3, 8:00-10:00pm – Meet the Teams, room 502B. Come meet members of the BrowserLab, Dreamweaver and Fireworks teams. Informal Q&A with everyone on the teams that are attending MAX.

Wednesday, Oct 5, 1:30-2:30pm – BrowserLab: An Online Service for Cross-Browser testing, room 504, with Kristin Long. Kristin will show how she uses BrowserLab for her work at MightyMinnow, and demo all the features. The BrowserLab team will be present to help with Q&A.

You can follow along on twitter by searching for #AdobeMAX.

We hope to see you there!

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

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

BrowserLab for Firebug and Firefox 6 compatibility

Update, August 18, 2011: Our new BrowserLab for Firebug extension, v1.0.0.1175P.307209, with compatibility for Firefox 6 is now live on the Mozilla Add-ons Exchange.

For those of you using our BrowserLab for Firebug extension, we wanted to let you know that there is a temporary incompatibility with the recently released Firefox 6. We’ve submitted an updated extension (v to the Mozilla Exchange team, and expect it to be available to you within the next couple of days. To check for updates, just choose Tools > Add-ons in Firefox 6, then choose Extensions.

If you’ve never tried BrowserLab for Firebug, this AdobeTV movie shows it in action.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab 1.6.3 with new Mac OS X browsers is now live

Today we have released a new version of BrowserLab for you, v1168P.306117, which has some nice improvements:

  • Chrome 13 beta was updated to the final release (Windows)
  • Firefox 4 was added (Mac OS X)
  • Firefox 5 was added (Mac OS X)
  • Flash Player was updated to v10.3 (Mac OS X)

We also updated our BrowserLab for Firebug Add-on for Firebug 1.8. You can find it on the Mozilla Add-ons page, or if you already have it installed, it will be updated when you update your Add-ons.

Finally, we have removed support for some older browsers now that they’ve significantly declined in usage. Safari 4 (Mac OS X), and Firefox 3 and 3.6 (Mac OS X and Windows) have been removed.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman