7

Today, Firefox 5 was released. If all goes according to plan, Firefox 7 will be out by the end of the year. Firefox has adopted the Google Chrome development model wherein version numbers are largely unimportant and so just supporting "the latest (publicly available) one" is probably the best strategy.

But how do you best test that? As my QA guys have pointed out, if you tell the client that you support "the latest version" but a version comes out that breaks your site, then you have a problem because now you've stated you support a web browser you don't. And since both Firefox and Chrome now update themselves automatically, the average person probably has no clue or care what version they're running. And having them either not upgrade or roll back is nontrivial.

I'm finding there are a number of organizations that mandate their employees use IE (the head of IT subscribes to the Microsoft school of thought), or mandate their employees use Firefox (the head of IT subscribes to the IE-is-insecure school of thought), so Chrome updating constantly was a non-issue. But now that Firefox is a member of that club, I can see this becoming a bigger issue soon.

My guess, in the case of Firefox, would be that the Aurora channel is the key, but what is the best way to approach testing it? Should we fix anything that comes up as an issue in Aurora, or should we wait until closer to the scheduled release? Do people automate this sort of thing?

Tom Kidd
  • 827
  • 9
  • 16
  • 2
    As far as talking to QA goes, you might want simply to specify the highest rev of FF (or whatever) that you have tested with. I've seen more problems from extensions breaking things than minor rev rolls from FF. Of course, now it *looks* like a major rev roll, but I just see that as marketing -- there are only so many changes you can make in a 6 or 12 month time frame and not completely break the code. One man's opinion. – Peter Rowell Jun 21 '11 at 21:35
  • Why not simply specify what specific browser versions you support? This way you don't get into as much trouble with your clients. – Bernard Jun 21 '11 at 21:36
  • @Bernard: The problem is that Firefox and Chrome update themselves automatically. You can potentially be launching a new version every time you start the browser. I could be wrong but I don't think that locking into an older version is going to fly for much longer. – Tom Kidd Jun 21 '11 at 22:21
  • 1
    Remember that large client-side unit test suite you have? Run it in firefox 5. All pass? You support firefox 5! – Raynos Jun 22 '11 at 09:16

5 Answers5

4

Let's reflect a bit here for a minute - the only browser in the last decade to cause major problems for existing sites when it changed version number was Internet Explorer.

I don't recall a single instance of a client calling me and telling me their site is now broken with the latest version of Chrome or Firefox. There might've been some very minor visual issues, such as not pixel-perfect padding / margin or something similar, but on the whole the standards-compliant browsers have been extremely consistent in how they render sites.

New features and APIs have been added in recent versions, but those should not break sites that did not use them. Experimental features usually use vendor specific properties and are used at the developer's discretion. You should never rely on an experimental feature that has not been stabilized yet.

So as far as I'm concerned, I'm only worried from the arrival of the next Internet Explorer version. Chrome, Firefox, Safari and the rest can keep updating as fast as they like, as long as they keep consistently rendering sites as they have for years.

I'm not saying you should not test your sites with new versions as they come out, only that it's likely to be much less of a problem than you are anticipating. My suggestion is to guarantee support for the major version (market-share wise) at the time of launch and one more future version for anything but Internet Explorer. IE's release schedule is lax enough that should not present a problem.

Eran Galperin
  • 1,592
  • 10
  • 26
  • I like what you're saying, but when I have managers asking me what versions to specify that we'll be supporting when we release something in, say, November, and they want to say "Firefox 4" and forget it when Firefox 6 will be out by then, and my QA guys don't want to move quickly to support a new version of the browser, which is understandable from a workload, what am I supposed to tell them when I get resistance to "just have the latest version" ? – Tom Kidd Jun 21 '11 at 22:25
  • My point is that for browsers other than IE, so far it has not been critical to specify which version exactly you are supporting ever since vendors fell in line with the standards. Interest holders such as clients and managers need to be briefed about the history of non-IE browsers in recent years so they can have more confidence that the product won't break under normal circumstances - which is what I think they really want to know, and not the specific version of a particular browser. QA guys on the other hand have to relent and agree to test browsers that have a significant market share. – Eran Galperin Jun 21 '11 at 22:54
  • 2
    @Schnapple: "what am I supposed to tell them"? Whatever was written into the contract or offering or marketing literature or sales pitch. The "QA guys don't want to move quickly to support a new version of the browser" is entirely the problem of the QA guys. That's 100% politics; not technology. Make it clear that they're not keeping up. Make it clear that clients and managers need to talk *directly* to QA. Not go through you. – S.Lott Jun 22 '11 at 00:43
  • I would say Firefox 4+. I have never encountered an issue where a site was developed on a standards compliant browser and was broken with a later release. In order for that to happen, you would have to exploit bugs in the older browser. People used to do that with IE6, but now it would be a very bad idea. – Andrea Jan 10 '12 at 17:35
3

I think the continuous browsers versioning will signify the end of the approach known as "supporting all of the major browsers".

From now on it will be "supporting the two latest releases of the major browsers". Testing everything back too the origin has become to much to handle. The Stack Exchange team has adopted more or less the same strategy (can't find the page where they talking about it).

Anyway the point of testing in all of the versions has faded away with modern browsers. it's been the case with IE that people were stuck with one particular (usually old) version for years. If a user has something different that IE, chances are he is educated about the browsers and has no problems updating it upon need. Most likely he still has the auto-update on which eliminates the problem entirely.

  • +1 for latest two releases. This is the way forward. Due to the current browser share climate we still have to support older browsers like firefox 3.6 though and I doubt we can drop IE8 once IE10 comes out. – Raynos Jun 22 '11 at 09:18
1

While it's easy for browser vendors, who are locked in a deep competition with each other, to release new versions, people don't upgrade nearly as quickly as browser versions are coming out. So it's important to ignore, at least somewhat, the rapid release schedule of the vendors and adopt a schedule that best suits your own application's needs.

Pingdom recently did a survey of StatCounter's data where they came up with a relevant hypothesis: people only upgrade when they get a new computer or a new operating system.

So, if half your users are still running Firefox 3.5 or Internet Explorer 7, it doesn't make a whole lot of sense to drop support for either: unless your application is mission critical, if they haven't upgraded already, they aren't going to upgrade just because you tell them to.

On the other side of the coin, if very few of your users are upgrading to the latest and greatest versions of browsers, it doesn't make a whole lot of sense to spend a ton of time testing against them.

But we're now at a point where most released browsers have a functional baseline: the idea that a new version of a browser will significantly break sites targeting older browsers is somewhat a thing of the past.

The one browser that has traditionally faced this problem, Internet Explorer, now includes support for X-UA-Compatible, so if you're unsure or not confident your site will function correctly on the latest release, you can target a specific version of IE's engine.

All this being said, all major browser vendors now provide development previews for the purposes of testing before they're released: you should rarely, if ever, be caught by surprise from a new major version.

What I personally do is go through the roadmap for the dev channel release (again, all major browser vendors generally publish what they hope to accomplish in the next major version) and assess whether those things affect my applications. If they do, then it's important to focus on those early on in the development cycle. Otherwise, I tend to do cursory tests towards the end to make sure nothing unexpected broke.

  • The problem is that thanks to automatic updating, people actually will start updating a lot more frequently. They won't even realize they're doing it. Thanks to Chrome's installation in the AppData folder, it doesn't even trip up UAC on Windows 7 when it updates. – Tom Kidd Jun 21 '11 at 22:23
  • @Schnapple Sure, but that largely doesn't matter anymore unless you're targeting edge, still not-finalized features. The one browser that has a history of radically changing its rendering, IE, has methods to target sites to a specific version, regardless of any upgrades done. –  Jun 21 '11 at 22:36
  • 1
    @Schnapple normal users are going to have chrome in the stable channel and that is _stable_. New versions of chrome really don't break much in terms of backwards compatibility. If users have Chrome in the dev channel and complain that your website is broken then it's not your responisibility – Raynos Jun 22 '11 at 09:20
0

You should be keeping an eye on your logs to see what browsers your clients tend to use. You then set a baseline version of each major browser and stick with it. However, you should also be aware of upcoming major changes to any given browser that is popular with your users.

For instance, if >60% of your users use flavors of MSIE, then make sure you're testing with latest builds of upcoming versions. Install VMs to test across multiple OSs if needed.

While most people don't consciously make the decision to upgrade, often that decision is made for them. At a previous job, we had spent most of a year re-designing and developing our new site. We had tested it against MSIE 6 and 7, as well as the current version of FireFox. Two weeks before we were to go live, Windows Update automatically pushed out MSIE 8 to the majority of our clients and we discovered that our CSS layout failed in the new browser.

Fortunately, we had followed best practices related to CSS layout as it was, an established CSS Grid library addressed the few issues that had been uncovered and the QA team was by then very familiar with testing for layout issues. We went live as scheduled, but afterwards, we made sure to test on upcoming versions of MSIE as builds were made available.

Adrian J. Moreno
  • 1,098
  • 6
  • 12
-2

By not using HTML for original content. Use some form of XML and then a transform language like XSLT to create the HTML/Javascript/CSS optimised for the (current) target browser set.

The HTML5 people have (possibly unwittingly, considering the polyglot mess) made the case for XML a lot stronger.

pgfearo
  • 944
  • 4
  • 11
  • 19
  • Are you serious..? – Eran Galperin Jun 21 '11 at 22:33
  • Its an option - my next website update will use XHTML5 polyglot templates and XSLT but all the content will come from plain XML. Then, when browsers change or HTML5 changes I just tweak the templates/XSLT, not the content. – pgfearo Jun 21 '11 at 23:08
  • You'd be better off serving a base document and using javascript (which is well supported already, and fast enough for the browsers you would be targetting) to enhance it as needed. XSLT sounds like a nightmare... – CurtainDog Jun 21 '11 at 23:10
  • @CurtainDog - Not everyone wants to rely on Javascript for everything. XSLT may sound like a nightmare for some, but relying on javascript for compatibility tweaks is a nightmare for others. – pgfearo Jun 21 '11 at 23:19
  • yes, sorry, I sounded too dismissive. I do think the idea has merit (I didn't downvote BTW). – CurtainDog Jun 22 '11 at 02:12