Wednesday, November 4th, 2009

MooTools Call to Upgrade

Category: MooTools

<p>A change in Firefox 3.6 has prompted a call to upgrade from the MooTools team. Earlier versions of the library used the document.getBoxObjectFor method for browser detection but as of Firefox 3.6, that method has been deprecated and no longer available:

The reason we stress the upgrade to MooTools 1.2.4 and MooTools 1.1.2 is the removal of the document.getBoxObjectFor method in the upcoming Mozilla Firefox 3.6 release. Within the browser detection code of MooTools 1.1 and earlier versions of 1.2, MooTools attempts to identify the Gecko engine by checking for the existence of document.getBoxObjectFor. Mozilla’s removal of this method in Firefox 3.6 effectively breaks Gecko detection in MooTools 1.1 and MooTools 1.2.3 down.

MooTools 1.1.2 and MooTools 1.2.4 now use the user agent string to detect the browser in use which helps to eliminate the issue. The team urges all MooTools developers to upgrade as soon as possible to ensure that your applications continue to function as expected. The updates are 100% compatible with their previous versions.

Related Content:

Posted by Rey Bango at 3:51 pm
28 Comments

+++--
3.4 rating from 90 votes

28 Comments »

Comments feed TrackBack URI

This shows why a framework should use feature testing instead of relying on browser sniffing. You’d think the guys behind MooTools would have learned but even in this upgrade they fail to address the real problem.

Comment by Jadet — November 4, 2009

@Jadet

All the big frameworks provide browser sniffing, but AFAIK only use it as a fallback when feature detection doesn’t go far enough (you can’t always feature detect inexplicable IE quirks, for instance) or adds too much overhead to a particular module. They all “rely” on browser sniffing at some point.

Comment by jlizarraga — November 4, 2009

@Jadet, they were using `feature inference`, assuming the browser was Gecko because an obscure function like document.getBoxObjectFor existed. In this case when they were trying to perform a generic test to sniff a browser they should and did eventually use a simple user-agent sniff. I think its fine for a framework to provide general UA sniffs as long as feature detection (testing that a specific feature works correctly before using it) is used throughout the framework and encourage in the dev community. Somethings like visual bugs or performance tweaks are perfect for UA sniffs.

Comment by jdalton — November 4, 2009

@Jadet

MooTools attempts to identify the Gecko engine by checking for the existence of document.getBoxObjectFor. Mozilla’s removal of this method in Firefox 3.6 effectively breaks Gecko detection in MooTools 1.1 and MooTools 1.2.3 down.

Isn’t the problem that feature detection failed here? Indeed: unless browsers can guarantee that they will not change/deprecate/remove methods, feature detection seems less of a panacea. A little study of the history of browsers makes me wary of having faith in browser methods remaining the same, always.

Comment by nataxia — November 4, 2009

@jlizarraga
The whole point of feature detection is to not have to use browser sniffing. If people use it sniffing as a fallback they should leave the coding to someone else. Most frameworks work towards removing all the internal browser sniffing. Those exposing sniffed browsers do this because people started to use them for their own code, if sniffing is used internally someone made the mistake to go with it in the first place.

Comment by Jadet — November 4, 2009

@jdalton: yeah that getBoxObjectFor sniff was pretty lame.

Comment by Jadet — November 4, 2009

@nataxia you are confusing `feature inference` and `feature detection`. .
.
Feature detection for example is checking that a browser supports document.querySelectorAll() and then maybe running a few tests to see if it works properly before forking the code to use the querySelectorAll() method. If it is not supported then you fallback on other code to simulate the functionality. So when a new browser like Chrome comes out you won’t have to adjust your detection because you test for the functionality of the specific feature you are wanting to use.
.
Feature inference is saying that because the browser supports the document.all collection we can infer that it also supports the ActiveXObject. So you rely on an assumption instead of testing the specific feature.

Comment by jdalton — November 4, 2009

Maybe it’s naive in some way I haven’t detected yet, but I’ve always felt the browser vendors should simply provide a JS function that returns a browser identifier object that uniquely identifies the browser type and version REGARDLESS of what the agent string is set to. Leave the agent string to the user if they want to muck with it, but make the value provided by this function be gospel.

The agent string is typically used on the server-side because it came about in an age where you didn’t do a whole lot of client-side coding… nowadays, when the client-side of the equation is so much more important (relative to what it was I mean) there’ s more of a need for a 100% accurate way to determine browser type and version. This would be an incredibly easy thing for vendors to add and it wouldn’t have any backwards-compatibility issues… at least, none I can see :)

Comment by fzammetti — November 4, 2009

Wow.. there’s no issue here. Firefox 3.6 is a new browser release with new features and the framework needs to update how it is going to detect this *new* browser. Old FF versions will still be detected fine (since they will still have this method).

When IE9, Safari 5, FF4, etc. are released; guess what? You’ll all need to do something different than you were for their previous versions to detect these new ones (read: update your code). Common sense.

Comment by rmg182 — November 4, 2009

@fzammetti: There will always be browsers trying to fake being other browsers so they are not left out, in the same way you now have useragent strings with ‘like Gecko’ in them. Opera has had the window.opera object with opera.version() for some time. It might be nice if others followed so client-side UA sniffing could become a thing of the past one day.
@rmg: No, you shouldn’t have to modify code every time a browser updates. Mootools could have avoided this by not sniffing out a browser based on a feature. If they used feature detection instead of relying on browser sniffing internally they wouldn’t even need an update, assuming they also stopped exposing browser sniffs.

Comment by Jadet — November 4, 2009

“Maybe it’s naive in some way I haven’t detected yet, but I’ve always felt the browser vendors should simply provide a JS function that returns a browser identifier object that uniquely identifies the browser type and version REGARDLESS of what the agent string is set to.”

That would be bad, because then programmers might use it. It’s not a solution that improves on any of the things that are bad about user agent strings.

Comment by Breton — November 4, 2009

From my perspective, this is one of those things that goes back and forth. At first, user agent strings were what we all used in our code (look back to 1998 to find JS libs that did this stuff for you) and then browsers started lying to us. So we stopped using the user agent string and started finding other things that made browsers unique. You can use feature detection for a lot of things, but not everything. And when a future browser comes out that has the feature, but implements it backwards or wrong, we’re in the same boat.

The fact is that browsers are inconsistent with each other. We author our sites to work with them, but go find a site with a bunch of javascript written for Firefox 1, or Netscape 4, or IE5, and I’ll show you a site that doesn’t work in Firefox3 and IE8.

MooTools is switching to user agent string and feature detection, but I promise you that in another year, or two, or three, sites using it, or jQuery, or YUI, or whatever, will not work with the latest browsers unless people upgrade their frameworks.

Indeed, this is the *point* of a framework. It abstracts these things from what *you* write, so that when it changes, you update the framework, but don’t have to change your code.

Comment by anewton — November 4, 2009

The problem is that people use feature detection for the wrong thing. We should not be making assumptions about a browser’s support based on the existence of certain properties or UA substring. Instead, test for an explicit feature *only when manipulating something directly related to said feature*. For reference, see jQuery’s method of browser support: jQuery.support

http://docs.jquery.com/Utilities/jQuery.support

The way jQuery uses jQuery.support internally prevents this type of compatibility issue (but not all)

Comment by posaune — November 4, 2009

Wow, all these attacks sound like total bullshit to me. If one of the features that jQuery used to determine positioning had been suddenly yanked and it failed in one browser I bet you all wouldn’t have your polka-dot girl panties in a bunch.

Next time save the rhetoric about such a pointless subject and compare library features and adherence to DRY, OO principles, then we can have a real debate.

What was the motto again? “Write less, do more”…hmm I think it’s more like, “Write less over and over again without employing any system thinking or basic computer science principles, then feel like you’ve done more out of ignorance.”

As Johnny Storm says: “Flame (war) on!”

Comment by csuwldcat — November 5, 2009

@csuwldcat I think most comments here have been constructive. If a framework is using feature detection correctly and a browser suddenly yanked support for a method it used to determine positioning, it would fallback on another solution and not cause a problem. When I write code I try to do it as basic as possible and then go back and add feature detection for native methods I might branch to if they are supported.

Comment by jdalton — November 5, 2009

You can use feature detection for a lot more than you think. If you have a browser compatibility problem that you think can’t be fixed with feature detection, chances are you’re just not trying hard enough.

Using this bizarre feature inference on document.getBoxObjectFor was a poor design choice by the MooTools developers. There can’t be much debate about that. To then replace this with UA string sniffing… well, I’m very sceptical that this is likely to be much of an improvement, but I haven’t looked at the MooTools code so I’ll reserve judgment.

@anewton: “MooTools is switching to user agent string and feature detection, but I promise you that in another year, or two, or three, sites using it, or jQuery, or YUI, or whatever, will not work with the latest browsers unless people upgrade their frameworks.”
If true, that sounds to me very much like an overwhelming reason not to use these libraries. Surely the point of them should be precisely the opposite. If you use feature detection sensibly then you simply won’t need to change your code when a new browser comes out.

Comment by timdown — November 5, 2009

@csuwldcat: I guess you assume that everyone in here is a jQuery fanboy. I could write about bad discissions they made all day and do the same about frameworks I use myself. If I say something it’s only to make them better.

Comment by Jadet — November 5, 2009

@csuwldcat it’s incredible, on top of the problem this creates to users you tell that at least this was based on “basic system thinking and computer science principles” … before trying DRY/OO and stuff give us some working code that can last more than just a few months.

@anewton you are saying that since Mootools encountered this sniffing related problem (in late 2009) you are sure that any other code will have the same problems, isn’t this a bit out of truth ?

@timdown I strongly agree with all you said, especially the last part.

Comment by dperini — November 5, 2009

I second fzammetti in that browser vendors should come up with a better and more consistent way to expose the information about the browser, version, build, os, vendor, etc. The useragent string is a piece of crap – hell, IE still has “Mozilla” as the first bit in its string!! ;)

Relying on the useragent string is a bad choice as it can only really be used for past and present browsers – there’s no guarantee what future strings will look like and they can’t be correlated to features (as the features likely don’t exist yet).

Feature detection (not inference) is the way to go forward.

To sum it up: Feature detection is (more) future-proof, useragent sniffing is legacy/backward compatibility.

Comment by rasmusfl0e — November 5, 2009

@everyone

I am going to go out on a limb and guess that many of you who posted about the poor foresight on the Mootools team on this issue also are of the belief that Classes and module patterns are not JS things and “you should stop trying to make js something it’s not” (I can’t tell you how many times I have heard that load of s…)

Are you all going to crawl back here and extol the fantastic foresight and the perseverance of the Mootools team when ECMA Harmony drops?

http://en.wikipedia.org/wiki/ECMAScript#Future_development

I am going to roll on the f*ng floor when the new Classes and module systems are implemented. But wait…C..C..Classes? Gee shucks, guess they told ya so huh? Epic foresight, epic.

When all you “ewww js Classes, no way” folks do have a plate of my shorts in front of you at your dinner table, just make sure to take a picture for me so I always have the memories.

Comment by csuwldcat — November 5, 2009

@csuwldcat: Classes have nothing todo with what’s been discussed. Mootools wasn’t the first to come up with that in javascript and isn’t the only one doing it. You shouldn’t focus too much on one framework.

Gotta love those Mootools fanboys jumping to the rescue everytime someone writes about ‘their’ framework. There’s no need for that here since they admit making a mistake with this release, all we’ve pointed out are better alternatives.

Comment by Jadet — November 5, 2009

@jadet, I agree entirely with your last statement.

Look, the MooTools team (I’m one of them) made a decision on browser feature management in MooTools 1.0. The codebase for this management didn’t change a lot as we iterated over new things. We should have revisited it sooner, and we take to heart the comments about feature detection. Expect this to get better in future versions of MooTools. We do plan on still supporting browser detection – specifically the ability to tell what browser version you are in – to offer backwards compatibility. But we will be avoiding using these values to imply feature support as we iterate forward.
.
@csuwldcat – this thread is more about MooTools fixing something that is going to cause a lot of people headaches and getting the word out that a solution is available for an impending problem. Expressing our personal opinions about which framework is more teh awesomez isn’t going to shed any light on browser feature detection issues.
.
@timdown – my point is that JavaScript frameworks are, by definition, abstractions away from the native implementation of JavaScript. To do this, they touch the very foundations of the native implementation and, as we progress the standards of that language forward, that native implementation will change. Do you think that the technology behind web sites will remain unchanged for the next 5, 10, 15 years? At some point, something will change that affects jQuery 1.0, Dojo 1.0, YUI 1.0, MooTools 1.0. When that happens, sites still using those libraries will break for visitors using those new browsers. If the vendors of these libraries release fixes for them, then the authors of those sites don’t have to go re-write all their JS; they just update their library. That is their value. If you didn’t use a framework, and you touched these foundations yourself (i.e. you wrote your own abstractions that detected features and whatnot), you’d have to rewrite YOUR stuff.

And lest you think that this won’t happen at some point, pay closer attention to the nightlies of webkit and gecko and chrome. They push changes all the time that break the unit tests of these libraries. We give them feedback and they react 99% of the time. In this case, Mozilla decided to stay with it’s decision to remove this method. We respect their right to do that and don’t blame them for this situation, but the fact remains that Mozilla is making a choice to remove a feature that will break a bunch of web sites. It will happen again in Firefox or some other browser, I promise you.

Comment by anewton — November 5, 2009

@everyone: My bad, I got defensive on a passionate subject, my apologies!

Comment by csuwldcat — November 5, 2009

@anewton: I feel like you should be dubbed the official MooTools press/evangelist guy. You do a great job at putting out fires and are very neutral in the way you do it.

Comment by merrickchristensen — November 5, 2009

@merrick that’s david walsh’s territory. I just want to have these discussions we have are profitable is all.

Comment by anewton — November 5, 2009

@anewton: Actually I do expect (library-free) code I’m writing now to work unchanged in the browsers of 5 or 10 years’ time, and I think you and all the major library authors should be writing code with the same aim in mind. Feature detection is not only about testing that objects and methods you intend to use exist but also testing they work as you expect and using alternatives if not. If your code is going to break if a single browser manufacturer changes or removes a single non-standard feature that you were not even using for its original purpose then it is your code that is at fault, not the browser manufacturer.

Comment by timdown — November 6, 2009

@timdown I agree that using methods in the manner we were is a bad practice; we are totally owning up to that bad decision.
.
“If your code is going to break if a single browser manufacturer changes or removes a single non-standard feature…” I’m saying that at some point the API of JavaScript will change in some way that breaks something somewhere, whether you write it or I do. The browser vendors themselves are part of the problem here; they introduce non-standard APIs all the time.
.
Show me ANY 10 year old technology that still works the way it did. The web is not always 100% backwards compatible. I can’t even imagine what the web will be 10 years from now. What if browsers implement technologies that completely obviate the need for Flash? And after a while Adobe stops pushing it, so that a significant portion of users just don’t have it? That’s ALREADY happening with the mobile web. So suddenly sites that were built 3 or 4 years ago that used Flash for navigation or whatever don’t work. Now, you nor I built sites like that in all likelihood (I didn’t at least), but many did.
.
My point is that modern development practices involved a LOT of programming on the client in a runtime environment that changes a lot. Even if you didn’t use a framework and followed standards, at some time – whether it’s 5, 10, or 30 years from now – the web will be something different.
.
Should we (MooTools) have abandoned this practice sooner or not used it at all? Yeah, and we’re copping to it. But the point here is that it’s a simple fix; you don’t have to go rewrite anything. Just download it and deploy it.

Comment by anewton — November 6, 2009

Leave a comment

You must be logged in to post a comment.