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

Posts tagged "Firefox"

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.

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?

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.

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.

The team has been looking forward to starting this blog, and hopes it will allow us to engage more fully with BrowserLab’s users. We’re planning to post regularly on all sorts of topics, ranging from announcements, to technical information, best practices and tips on how to use BrowserLab most efficiently, and how to work around bugs or other limitations.

We’ve been busy recently, creating new features, new videos, and presenting BrowserLab sessions at MAX. We’re also about ready to launch a new BrowserLab Prerelease program.

If you haven’t tried BrowserLab, we hope you’ll give it a try. We’re confident that you’ll save time, money, and be delighted with how easy it is to test for cross-browser compatibility. You can find BrowserLab online at http://browserlab.adobe.com. An AdobeID is required to sign in. (It’s free, quick and easy to create an AdobeID if you don’t already have one.)

On behalf of the whole team, thanks for checking us out – we look forward to sharing and interacting with you on this blog.