BrowserLab for Firebug and Firebug 1.8.0 compatibility

Update, August 11, 2011: Our new BrowserLab for Firebug extension, v1.0.0.1168P.306117, is now live on the Mozilla Add-ons Exchange.

For the most part, our current BrowserLab for Firebug extension is compatible with Firebug 1.8.0 which was released earlier this week. There is one very important part that is not working – Preview Local Source. We have a fix for this, and it is currently being tested and will be submitted to Mozilla for their testing process this week. I expect a new BrowserLab for Firebug to be available publicly within a week.

I’ll tweet, and update this blog when it is final and live.

If you’re not sure what BrowserLab for Firebug is, check out this short AdobeTV video.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab v1.6.2 with Firefox 5 and Chrome 13 support is now live

This afternoon, we released BrowserLab v1.6.2 which includes the following changes:

  • Chrome 13 (Windows) support has been added
  • Firefox 5 (Windows) support has been added
  • A fix that improves BrowserLab’s support for sites built with the SilverStripe CMS
  • Additional bug fixes and improvements

Someday in the not too distant future, we’re going to remove Firefox 3.0 and 3.6 from BrowserLab. If you’re wondering why we would remove support for older browsers, it is to keep BrowserLab lean and mean, and keep our backend costs in check. We can’t keep older browsers around forever, and we’ve seen significant drop-off in market share for these older versions. If you have objections to this, please let us know why. You can let us know how you feel by posting here in the Comments, or on our BrowserLab User Forums.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab for Firebug, and Firefox 5

As of July 12, 2011, a new version of our BrowserLab for Firebug extension is now available on the Mozilla Exchange. This version is compatible with Firefox versions 3.x – 5.x.

We expect to see new major versions of Firefox more frequently, which will temporarily create an incompatibility for BrowserLab for Firebug. We will do our best to update our extension quickly when there are incompatibilities. In the mean time, consider holding off on upgrading Firefox if using the BrowserLab for Firebug extension is a critical workflow for you.

Bruce Bowman
BrowserLab product manager

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

BrowserLab for Firebug and Firefox 5 incompatibility

Note: As of July 12, 2011, the updated extension is now available on the Mozilla Exchange.

For those of you using version 1.0.0.1009P.274944 of our BrowserLab for Firebug extension, we wanted to let you know that it is not compatible with the recently released Firefox 5. This is just a temporary incompatibility – We’ve submitted an updated extension (v 1.0.0.1117P.302658) to the Mozilla Exchange team, and expect it to be available to you within the next few days.

For those of you that may not have tried BrowserLab for Firebug, this AdobeTV movie may help you decide if you can use it in your workflows.

Generally, 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 Firefox and/or Firebug until you also see an update to our extension.

 

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

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, dropbox.com is on Microsoft’s Compatibility View List, which causes all content from the dropbox.com 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 dropbox.com 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.

Feedback

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

References

Understanding the Compatibility View List: http://msdn.microsoft.com/en-us/library/dd567845(VS.85).aspx
Current Compatibility View List: http://ie9cvlist.ie.microsoft.com/ie9CompatViewList.xml

BrowserLab 1.6.1 is live: now with Chrome 11

Today we rolled out BrowserLab v1.6.1 which includes some nice changes:

  • Chrome 11 (Windows) was added, and Chrome 9 was removed
  • We’ve added an in-client poll/survey that asks you 2 simple questions. Please take the survey as it will only take you a minute, and it will help us measure and improve the service
  • We fixed several bugs, including some fixes for isses we had loading pages that use Modernizr
  • We increased the maximum range value for our Delay feature from 10 to 20 seconds

We recently spoke to some BrowserLab users that were not aware of the Delay feature in BrowserLab. If you’ve never tried it, the Delay feature allows you to specify how long BrowserLab should wait after loading your page before the screenshots are taken. This is useful when you have dynamic content such as movies, animations, etc that needs time to load or play before you want your screenshot to be taken. Generally, you’ll want to leave the Delay set to 0 unless your content is not loading, or it will needlessly increase the time it takes to return your screenshots.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

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 v1.6 is now live

Coinciding with the release of Creative Suite 5.5, we’re now live with BrowserLab v1.6. This release adds some nice new features, such as Follow Links, URL History, new Italian and Spanish language support, as well as workflow improvements with BrowserLab for Dreamweaver. BrowserLab can be used in the following ways, one of which is sure to fit into your workflow:

  • BrowserLab Client: Access BrowserLab in your web browser, enter the URL, and do your cross-browser testing.
  • BrowserLab for Firebug: This Firefox extension allows you to test local content, that might have been changed using Firebug. It also enables you to test sites that are behind HTTP Authentication – just open your site in Firefox, log-in, then use BrowserLab for Firebug to Preview Local Source. We have a short AdobeTV movie showing this workflow
  • BrowserLab for Dreamweaver: Using Adobe Dreamweaver CS 5 or CS 5.5, you can send your current document to BrowserLab. This works with files that are on your Remote or Local servers. Using Dreamweaver’s powerful Freeze JavaScript feature, you can browse your site in the built-in WebKit browser, get it into a state, freeze, then send that to BrowserLab. BrowserLab will render your page, in that frozen state across all of the browsers in your Browser Set. Another AdobeTV movie shows the BrowserLab for Dreamweaver workflow.

On behalf of the whole BrowserLab Team, I’m happy to announce the immediate availability of BrowserLab v1.6. We hope you enjoy using it as much as we enjoy making it!

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

 

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