An easier, faster way to do cross-browser testing.

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

(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.

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 information; Linksys 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 http://www.thismachine.info/ as a URL to BrowserLab. The returned screenshot will show our current egress IP.

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 http://browserlab.adobe.com, 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.

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.

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 Fonts.com 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.

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:

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.

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:

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?

This is most likely our last blog post for the year. As we leave 2010 behind, we’re very excited about all of the new features we’re working on – 2011 is going to be a great year for the BrowserLab service!

In our next release, which will be early in 2011, we’re planning to add Chrome 8 for Windows and OS X, and any updates for our beta browsers. We’re also planning on removing Safari 3 and Firefox 2 at that time.

With the addition of these new browsers, and the support we already have for Safari 5, you’ve got an excellent test environment for helping you test with a wide range of browsers, from the legacy browsers like IE 6/7 to the newest browsers that support HTML5 and CSS3.

Update Dec 11, 2010: We’ve updated our BrowserLab for Firebug extension to version 1.0.0.867P.265076, 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.

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.