A long-standing feature within Mozilla’s rendering engine has been the getBoxObjectFor method. This particular method was a way for XUL elements to efficiently determine their position, amongst other things. A couple of years ago this feature started to be used by the general web-developer world. This was quickly realized to be a major mistake.

Mozilla developer, Robert O’Callahan, outlined the concerns quite well:

• It’s not even a quasi-standard.
• It’s not a very convenient API to use or implement because it introduces an
  extra object.
• In Mozilla it’s only available when XUL is enabled, so some embedded Geckos
  don’t have it — actually, it’s worse, they have the function, but it always
  fails (such as in Camino).
• When it is available, it contains a bunch of XUL-specific methods that don’t
  make sense for HTML but people might try to use anyway.

A problem, though, was that no one was particularly excited about removing the method since there was no alternative to jump to. That’s no longer the case – now that there’s the CSSOM View getBoundingClientRect method in Firefox 3, which fills this gap quite nicely.

And now, getBoxObjectFor is being phased out, in two steps:

1. It’s being deprecated in Firefox 3. Any attempts to use it will throw a warning to the console (but continue to work).
2. It will be removed, completely, in the next version of Firefox.

Because of this you should begin moving to getBoundingClientRect tout d’suite. Although, if you’ve been writing your code using good object detection practices then this shouldn’t be much of a problem.

The Relationship between HTML and XUL

In order to understand how a feature like this could have been introduced in the first place you need to have an understanding of how Firefox (and most other Mozilla-platform-based applications) are constructed.

For those not familiar with it, XUL is a markup language designed for constructing user interfaces. In many ways it behaves very similarly to HTML (it renders some things very similarly – and it fully supports CSS, JavaScript, and the DOM). The Mozilla platform uses XUL to render all of its user interface components – and uses the same exact rendering engine to render the interface as to render the HTML pages that you view every day.

This means that there’s one rendering engine displaying everything that you see when browsing the web, with Firefox. Because of this tight relationship between the two markups (and their associated CSS properties and DOM methods) there’s a lot of work done to make sure that only the correct functionality is exposed in the right situations. However, this was not always the case.

The issue that occurred with getBoxObjectFor isn’t that it was accidentally exposed (in that it occurred as an oversight) but that it was made available without first consulting the correct standards bodies or attempting any type of web-accessible-content moderation. The Mozilla project used to be very loose when exposing XUL/Mozilla-specific methods (in my opinion) however that has greatly changed. Newly-exposed functionality is thoroughly examined, analyzed, tested, and vetted for all possible uses – in addition to having active conversations with the appropriate standards bodies (W3C, WHATWG, ECMA, etc.).

This movement is incredibly important for a browser to make. Properly analyzing features will avoid painful situations like the one we’re encountering now (in which users of an undocumented method now have to adapt their applications). This is not to say that this is a particularly new thing for Mozilla to do, but it’s just that we’re getting better at the process (more eyes watching tends to help, as well).

We can see this process in action with a feature that didn’t make it in to Firefox 3: Web-accessible native JSON support. While native JSON support was added to the Mozilla platform well in time for Firefox 3 (it’s used extensively to power backend features) it didn’t make the cut for being made accessible to web pages, mostly for two reasons:

1. Lack of standardization. The ECMA TG1 committee (which is working to standardize ECMAScript 4) was originally attempting to include native JSON support in the next version of the language – however that fell apart and it was deemed to be ‘up to the implementors’ if they wanted to include it.
2. Lack of proper security vetting. Exposing a whole new API to web applications opens a whole new vector for possible security problems. To counter any issues there needs to be serious analysis before making anything public.

For both of these reasons it was decided that it was better to play it safe with this particular feature and hold off until the next release of the browser (when there would be more time to properly analyze its full impact).

This vetting process is now quite widespread in the Mozilla world, along with the practice of extensive automated testing, and it’s really fantastic. The result is a browser that’s more stable and secure but still able to provide desirable innovative features that web developers need.