Author Archive: Bruce Bowman

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

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

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

We hope you enjoy BrowserLab for Firebug!

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

Release 1.5.4 adds Firefox updates

Today, we have updated BrowserLab with the final Firefox 4 (Windows), and Firefox 3.6.15 (Windows). BrowserLab 1.5.4 is now live!

We have completed work on our BrowserLab for Firebug extension adding compatibility with Firebug 1.7, and submitted it to Mozilla. We expect it to go live on the Mozilla Exchange within a week.

We’d really appreciate it if you’d tell your web pro friends about BrowserLab! In addition to this blog, there are a few ways to stay in touch with us:
Facebook: http://www.facebook.com/browserlab
Twitter: @adobebrowserlab@brucebowman
BrowserLab User Forums: http://forums.adobe.com/community/cslive/browserlab

Bruce Bowman
Adobe BrowserLab product manager