Posts tagged "Browsers"

BrowserLab update removes IE7

Internet Explorer 7 has been retired from BrowserLab

Today we have pushed a minor new version of BrowserLab that no longer contains Internet Explorer 7. If you still need to test for IE7 in BrowserLab, you can do this using IE8 and a by adding bit of code to your page(s). To learn more about IE8′s Compatibility Mode, you can read about it in these Microsoft Blogs:

Introducing Compatibility View
Understanding Compatibility Modes in Internet Explorer 8

Remember to remove that code once your testing is complete, unless you want your IE8 visitors to see your page as they would in IE7.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab adds Chrome 18 support

BrowserLab v1.6.6 is now live, and contains the following changes:

  • Chrome 18 support (Windows)
  • New login screen

If you have any problems logging in to BrowserLab, please clear your cache and restart your browser, then try again. We made some significant changes to the login mechanism, so this step may be necessary.

We will update BrowserLab again soon to add the latest Flash Player, and a newer version of Firefox.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab 1.6.4 with new Chrome and Firefox browsers is now live

Today we have released a new version of BrowserLab for you, v1211P.312309, with updated browsers, security patches and some minor improvements:

  • Chrome 14 was added (Windows), and Chrome 11 was removed
  • Firefox 7 was added (Mac OS X and Windows), and Firefox 4 was removed
  • Safari was updated to 5.1 (Mac OS X)
  • Flash Player was updated to 10.3.183.10 (Mac OS X and Windows)

We will include Flash Player 11 in our next update.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

BrowserLab 1.6.3 with new Mac OS X browsers is now live

Today we have released a new version of BrowserLab for you, v1168P.306117, which has some nice improvements:

  • Chrome 13 beta was updated to the final release (Windows)
  • Firefox 4 was added (Mac OS X)
  • Firefox 5 was added (Mac OS X)
  • Flash Player was updated to v10.3 (Mac OS X)

We also updated our BrowserLab for Firebug Add-on for Firebug 1.8. You can find it on the Mozilla Add-ons page, or if you already have it installed, it will be updated when you update your Add-ons.

Finally, we have removed support for some older browsers now that they’ve significantly declined in usage. Safari 4 (Mac OS X), and Firefox 3 and 3.6 (Mac OS X and Windows) have been removed.

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

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

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

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

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