Color Profiles in Firefox 3

April 29th, 2008

Deb Richardson wrote up an interesting piece today describing color profile support in Firefox 3. The result of a color profile is a more-accurate mapping from an original set of colors to better match the intended rendering. Profiles can be provided by the operating system (to provide better color distribution globally) or even locally by individual images.

For example, observe the following image which compares the difference between Firefox 2, Firefox 3 (with color profile support), and an image in Adobe Photoshop:

There is a noticeable difference between the rendering of the image in Firefox 2 compared to both Photoshop and Firefox 3 (in which they are rendered identically). All of this is due to the fact that Firefox 3 and Photoshop use the additional color profile information to get a better mapping of the resulting colors.

There's one tricky point, however: Color profile support is disabled, by default, in Firefox 3. However, it can be quickly enabled by installing the Color Management Add-on or by twiddling some options in about:config.

The reasoning for the feature being disabled was outlined for two particular issues:

1. There was a large 10-15% drop in performance when this feature was enabled. The extra time spent on large images began to add up quite quickly. Obviously this will be a point that'll be worked on in upcoming releases - but introducing a regression that large was pretty much unacceptable.
2. Plugins (such as Flash, Silverlight, Quicktime, etc.) did not do color profile correction, causing rough mis-renderings to occur. This correction is, unfortunately, left up to the plugins themselves - leaving this out of the realm of the browser itself. It's unclear as to how this will be resolved.

At the very least, however, you can grab the Color Management Add-on with your copy of Firefox 3 and begin to view your pictures with an extra level of color and crispness.

Tags: firefox, colors, mozilla, browser

17 Comments on 'Color Profiles in Firefox 3'

Ajax Accessibility

April 29th, 2008

A common concern of most Ajax applications has been around their resulting accessibility. While, arguably, it's possible to design some form of a usable web page without the use of JavaScript it should be possible - with the additional scripting information - to provide a better experience to users. It's at this point that the ARIA specification comes into play. A large set of interaction is defined within it which is able to help web applications communicate directly to a screen reader in an effective manner.

To get a feel for what this interaction looks like, take the example of ARIA Live Regions (more info). With this functionality it would be possible to keep a live-updated list of users and allow the screen reader to keep up-to-date.

Observe the following ARIA-marked-up HTML:

A couple settings are used to make this piece of HTML particularly interactive to the screen reader (the actual JavaScript that will update this list is left out - but needless to say nothing, in particular, is needed beyond simple DOM insertion and removal).

• aria-live="polite" How polite the live area is (as in, how likely is it to butt in to what the user is currently listening to/interacting with). The default is 'polite' - in that it waits until all forms of user interaction have been completed before describing the updates to the user.
• aria-relevant="additions removals" Only notify the user about new node additions and removals. Since we wish to provide the user with a live list of users we can expect them to be both transitioning online and offline - this will give us the appropriate level of updates to make this possible.
• aria-describedby="users-desc" A pointer to the element that describes the contents of the live area. If the user
  wishes to know more about what the contents of the field represent this element can be read to them.

What's most important about all of this, though, is that ARIA isn't just a pipe dream of functionality: It's implemented, today, in Firefox 2 and even more-so in the upcoming Firefox 3.

The Google Reader team recently took advantage of this and added full ARIA support to their application. It's safe to say that Google Reader is not a trivial application by any stretch, allowing this to demonstrate the feasibility of ARIA within large-scale web application projects.

In the course of their implementation they built a tool, AxsJAX, which injects ARIA usability enhancements into many pages using a bookmarklet, greasemonkey, or Fire Vox (a Firefox screenreader). They started by seeding a number of Google applications with this drop-in accessibility support (along with a few others, including the XKCD web comic).

I continue to be impressed with what can be accomplished with ARIA - and seeing the work that Google has been putting forth by implementing this functionality in their applications has been incredibly enlightening and encouraging.

Tags: ajax, javascript, accessibility, mozilla, firefox, aria

11 Comments on 'Ajax Accessibility'

Planning JavaScript 1.9

April 16th, 2008

The feature set for Firefox 3 has long been frozen, and committed - it's well on its way to becoming a polished browser, at this point. It's time to start looking ahead, specifically, at the feature set of JavaScript in the next version of the browser.

Traditionally JavaScript 1.X releases (1.6, 1.7, 1.8, and now 1.9) have served to introduce new features into the language that help to pave the way towards its next major release. The size and scope of the features have, generally, varied - the importance of generators and iterators - or let statements - are, arguably, much more than, say, expression closures.

However, since the final feature set for ECMAScript 4 (JavaScript 2) has calmed down, with implementors starting to lay their code on the line, it's becoming easier to get a full picture of what will be happening in the near future of the language.

A few of us Mozilla folk will be meeting tomorrow at the ECMAScript 4 implementors meeting in Newton, MA to discuss what features, and bug fixes, should be pursued. I have a few that, I feel, are no-brainers like a builtin Function.prototype.bind and a native JSON encoder/decoder.

It's doubtful that we'll be able to land too much with this release (we're hoping to get it out as quickly as possible, post Firefox 3 - so don't expect too much) but, as always, input is appreciated. At the very least, I'll be able to let you know where your suggestions lie within the scope of the language. I should have an update after the meeting with a full re-cap of what was concluded.

Tags: mozilla, ecmascript, javascript, firefox

23 Comments on 'Planning JavaScript 1.9'

Attack of the Enigma Browser

April 10th, 2008

I just had an epic phone call. I leave my cell phone number on my about me page since I tend to believe in the innate goodness of humans. It has yet to be proven true, thus far, but I'm willing to play the long game.

It started with an email from one 'Dennis Baer', followed immediately by a direct call to me (which didn't afford me any time to read it until after the call). The contents of the email are pretty much spot-on to what what he communicated to me:

Hello

I have endured enough of Firefox and have abandoned it along with K-Meleon and even Opera. For over 2 years the makers of Firefox would not acknowledge that FireFox used huge amounts of memory, would load pages slow and used so much cpu cycles that other programs slowed down. The makers of Firefox in my view just hoped people like me would not bother them with experiences of huge memory use and slowing down of the entire machine! and just go away.

This has come to an end as of today.

I suggest Windows users abandon Firefox for now and get a browser named Enigma.

You can download it for FREE at http://store.democratz.org in which you will find the link just right above the products section.

I have 35 tabs open right now and it does not slow down the machine. The page loading appears much faster than Firefox and when you use it, you will laugh at Firefox slowness. This browser works better than Opera and Safari and Internet Exploder too.

Enjoy.

I realize that you work for Mozilla. You will not like finding this out when droves of people will abandon the Firefox Behemoth. I'm spreading the word far and wide about Enigma. Noone should have to put up with Firefox any longer until Mozilla gets their act together.

I just found enigma on the web yesterday and I now consider myself free free free from this Firefox problem.

Ironically, the link that he provided doesn't seem to actually work. While I was on the call with him I googled for the phrase 'Enigma browser' and found two, nearly-identical, pages that both provide this 'browser':

• http://www.suttondesigns.com/
• http://www.advancedbrowser.com/

(I don't recommend downloading them, they may contain virii or spyware.)

So while I listened to his enraged ranting I read up on this browser. Apparently it's a skin on top of Internet Explorer 6.0 - in sort of an MDI:

He repeatedly stated phrases like "Firefox use to be good, but it's gone downhill - it sucks!" and "It's even better than Opera and Internet Exploder [sic]!". I asked him if had had a chance to try Firefox 3 to which he stated "Yeah... it BLOWS!"

I could only assume that he didn't know that I worked for Mozilla - until he mentioned that I was "the only Mozilla employee that he could find on the Internet." Of course, during all of this it was all I could do but keep from laughing out loud. I was also on IRC, updating my co-workers in the Evangelism team as the call progressed - much to their surprise and amusement. I was sure to ask him plenty of questions - I figured that I'll only be sold this browser once, might as well make it worth my time.

After he was done enumerating the benefits of the Enigma browser, over Firefox in particular, I thanked him for his time and explanation. I'm still about 70/30 thinking that this was serious vs. being a huge prank. Regardless, my hat is tipped to one Dennis Baer: That took some serious balls - astroturfing on a scale never before seen.

Update: This quote from their FAQ is fascinating on so many levels: "Is Enigma Browser a secure browser?
 Yes, Enigma Browser is secure. Since it's based on Internet Explorer, Enigma Browser is as secure as Internet Explorer."

Tags: mozilla, firefox, browsers

42 Comments on 'Attack of the Enigma Browser'

Timer and Interval Offset

April 10th, 2008

I've got another crazy-weird setTimeout/setInterval behavior that you may not know about. However, unlike my previous discovery, this one may actually be useful.

Observe the following, seemingly innocuous, code:

In particular pay attention to the use of the first argument within the callback function. Running this code in any browser, but a Mozilla based one, will give you the expected "undefined undefined undefined ...".

However, running the code in Firefox gives you some interesting results - something like the following:

Results: 4 -8 -7 -3 6 1 -1 -3 0 0

What are these numbers? Simply, they represent the time, in milliseconds, the callback was called away from the desired callback rate. In the above results the first call was called at 104ms, the second 92ms later, the third 93ms later - and so on.

The immediate advantage to this is in the ability to create ultra-precise animations and renderings. Typically, in order to do this, you would have to keep running logs of the timer calls (restricted by the extra overhead of the JavaScript execution). Whereas with this extra offset information you can easily determine the exact timer differences, as specified by the browser.

I'm curious to see how this could be used. Timer quality analysis? Detecting simultaneous timer execution? Dunno - there's definitely potential, though.

Tags: javascript, mozilla, firefox, timers

16 Comments on 'Timer and Interval Offset'

Firefox Personas

April 4th, 2008

The Mozilla Labs team has been busy working on some new extensions to enhance user experience while testing out new concepts. One extension that recently got a major update was Personas.

The premise behind the extension is that it's currently too difficult to trivially theme and customize your Firefox experience. To counter this Personas makes the experience fantastically simple. For example, the following can be achieved using only a single image (which is seamlessly chopped up and positioned by Personas):

Now what I find to be especially interesting about this extension is the recent introduction of dynamic content into the rendering area. Instead of requiring the use of an image you can now specify a live URL (which can contain any number of things - including images, SVG, Canvas Element, JavaScript, etc.).

Here's a quick peek at putting a live Google map behind the top toolbar area of the browser:

Users are starting to contribute their own, like this page of a live web cam watching a university in Germany.

I'm really excited by this super-tivial means of styling an application. It's like taking the best part of HTML/CSS/JS widgets and combining it with trivial user customization and community.

While the end result may, or may not, look glamorous (depending on your taste) it's undeniable that simple user customization is a quick trip to get users more excited about their experience (making the browser 'their own'). I'm definitely curious to see what will built with this tool - especially now that dynamic content is being thrown in to the mix.

Update:

I was able to get a code example from Chris Beard for developing one of these advanced Persona extensions. To quote him:

You just need to put in script or content within the header/footer blocks. Also adding support so that it will pop up a window on first run so you can prompt for settings (e.g. flickr tags to use to render a photo mosaic) as well as an options window which users will be open for each Persona from the main interface.
...
The URL gets called every 60 minutes loading into a background iframe. The iframe is then captured every minute with the resulting image transfer to the chrome as a PNG data URL. No user content is privileged.

This is especially interesting since you can seed your browser layout with personal information, as he mentioned (photos from your Flickr stream, weather for your location, etc.)

Tags: browser, firefox, mozilla

12 Comments on 'Firefox Personas'

The getBoxObjectFor Apocalypse

March 31st, 2008

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.

Tags: javascript, mozilla, firefox, xul

4 Comments on 'The getBoxObjectFor Apocalypse'

Firefox 3 Memory Use

March 13th, 2008

Mozilla developer 'Pavlov' wrote up some extensive details on memory use in Firefox 3. I highly recommend that you check it out.

I borrowed some of his data and created another view of the results. For example, here's the results from Windows Vista of a number of browsers:

Note that both Safari 3 and IE 8 crashed during the test (which was a page runner which automatically opened and closed groups of web pages) so accurate numbers weren't able to be achieved for them. Some preliminary numbers show Safari 3 on a similar path to IE 7 (Stuart mentioned that IE 8 showed a similar path, as well).

It's great to see the massively-improved memory use of Firefox 3. It far excels anything that we offered, previously, and seems to best all other browsers on the platform.

Now, obviously, Windows Vista isn't the only platform available. I, personally, use OS X and am interested to see the memory numbers there as well. One portion of Stuart's blog post that I found to be particularly interesting was the discussion of measuring cross-platform browser memory use - and how difficult it can be. Here's how he explains it:

The short summary is Windows Vista (Commit Size) and Linux (RSS) provide pretty accurate memory measurement numbers while Windows XP and MacOS X do not.

...

On Mac, If you look at Activity Monitor it will look like we’re using more memory than we actually are. Mac OS X has a similar, but different, problem to Windows XP. After extensive testing and confirmation from Apple employees we realized that there was no way for an allocator to give unused pages of memory back while keeping the address range reserved.. (You can unmap them and remap them, but that causes some race conditions and isn’t as performant.) There are APIs that claim to do it (both madvise() and msync()) but they don’t actually do anything. It does appear that pages mapped in that haven’t been written to won’t be accounted for in memory stats, but you’ve written to them they’re going to show as taking up space until you unmap them. Since allocators will reuse space, you generally won’t have that many pages mapped in that haven’t been written to. Our application can and will reuse the free pages, so you should see Firefox hit a peak number and generally not grow a lot higher than that.

I think it's great to see these numbers come in. In many ways Firefox 3 is going to be a very different browser from its previous instantiations. I've, personally, been using it as my primary browser for a while now and have enjoyed the increased performance. It really does feel - and really even look - like a whole new browser.

If you'd like to try Firefox 3, especially without disturbing your current setup, it's really easy - and I've even written up instructions to help you out.

Tags: firefox, performance, browsers, memory

27 Comments on 'Firefox 3 Memory Use'