Archive for April, 2011

New BrowserLab v1.6 Coming Soon!

Next week, we’ll be launching a new version of BrowserLab with some new features that we think will help you work more quickly and productively.

  • You’ll now be able to follow links in BrowserLab. As you mouse around over the screenshots, you’ll see the cursor switch to the Hand cursor when you’re over a link that BrowserLab can follow. Hold Control (Windows) or Command (Mac OS) then click the link to have BrowserLab follow that link and request screenshots.
  • There will be a new URL History feature, that will keep track of the tests you’ve been doing, and allow you to quickly reload them. This will work very similarly to how the Back and Forward buttons work in a browser. You’ll also be able to click the Address Bar to drop down a list of all of your recent tests, then choose a specific item. When you use the URL History, we’ll quickly reload any cached screenshots, so in most cases they will not need to be re-requested from our browser servers. Of course, you can always use the Refresh button to force the screenshots to be re-requested if you like.
  • We’ve expanded our language support to include Spanish and Italian language versions.
  • Safari 3, Firefox 2, and older Chrome browsers will be removed, as their usage levels have dropped to the point that keeping them in BrowserLab is no longer needed.

Watch this short video on AdobeTV that shows the new features being used to test a site in BrowserLab.

We hope you enjoy BrowserLab, and these new improvements. We’d love to hear from you in the comments.

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

BrowserLab for Firebug update

BrowserLab for Firebug has been updated for compatibility with Firefox 4 and Firebug 1.7. It is now available for download from the Mozilla Exchange, and can be updated by using the Add-ons Manager in Firefox.

If you’re new to our BrowserLab for Firebug extension, you may be wondering why you would need it. BrowserLab for Firebug extends the usefulness of the BrowserLab service by enabling you to test pages that are not published on an internet web server. You can preview your html pages in Firefox on your local computer, then use BrowserLab for Firebug to push the local source to the BrowserLab service, where it will be rendered in multiple browsers. This means you can use all the power of Firebug to poke, change and debug your page locally, then test those changes/fixes across browsers in BrowserLab.

Another good reason to use BrowserLab for Firebug is to test sites behind HTTP authentication. E.g., let’s say you’re working on a new site for a client, and have the site hosted on a test server you use. Because the site is confidential, you’ve enabled simple HTTP authentication on the site. If you tried to view a page on this site using the BrowserLab client at, you’d find that the authentication prevents our browser servers from seeing your pages. But with BrowserLab for Firebug, you’d simply open Firefox, log into your site, then use BrowserLab for Firebug to Preview Local Source to the service, and see your page rendered in multiple browsers.

We hope you enjoy BrowserLab for Firebug!

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman