thoughts on mozilla

Doug Turner – a platform and mobile engineer with the Mozilla Corporation – has a post up discussing a new feature that may one day come to Firefox: desktop notifications.

Turner’s proposal would allow websites to display notifications to users, with their permission, of course. On first use, the website would ask for permission to show notifications, much like websites can do now with geolocation (a project Turner worked on previously).

Prior to creating his own, basic implementation, Turner reviewed two other proposals: WebNotifications and the Google Gears Notifications API. Astute readers will note that both of these specifications have been written by Google. Because of this and because of their inclusion in the now-defunct Google Gears, it’s very likely that Chrome will ship with desktop notifications at some point in the future.

The comments on his post are quite heated and some discuss a couple scenarios when websites could easily take advantage of users after they allow notifications. Regardless, the feature is very likely to move forward, given previous work by Google on the concept.

For more information, follow the bug in Bugzilla.

At the end of each quarter, each group within Mozilla (including the Foundation, Corporation, and Messaging) creates a set of goals for the next quarter. Some groups opt to publish these publicly, though most keep them internal-only.

The platform team (as well as the Firefox team) has consistently posted their goals publicly, allowing greater insight into where their effort is going for the next three months.

In the quarterly goals published for this coming quarter, there are a number of interesting line items that will be worked on this coming quarter. Quoting, out of order:

• Javascript performance near or even with Chrome 5 on their benchmarks (within 20% on SS, 30% on V8), with substantial wins on our benchmarks. (Windows, in-browser.)
• Security: zero reproducible high/[critical bugs older than] 30 days
• Fully support the WebGL 1.0 spec, with support turned on by default in a Firefox 4 beta on platforms that support OpenGL or OpenGL ES.
• Finish and land CSS Transitions
• Be prepared to ship [out of process plug-ins] for Mac OS X.

Several line items this quarter reference Chrome 5 and Mozilla playing catch-up to its speed. While this hasn’t been played up in the media, Chrome has been running rings around Firefox in some of the more popular JavaScript tests.

Kudos to the Platform team for continually publishing these. For reference, here are the goals for Q2, which is ending in a few days.

Earlier this week, Adobe shipped Flash 10.1 for Android devices. As Mozilla continues work on its port of Firefox to Android devices, its still unclear what its stance on Flash will be.

Mozilla continues its work porting Fennec to the multi-process Electrolysis project, which will improve stability of any mobile Flash browser.

At the platform meeting this week, there was much discussion over the version of the next Gecko release, on which Firefox 4 will ship.

For the past two Gecko releases, Mozilla has opted to version them as “sub” versions of the 1.9 branch, despite their relatively sweeping changes. In doing this, Mozilla has also guaranteed that frozen interfaces would remain frozen. With the coming of 2.0, Mozilla is changing its stance on frozen interfaces. From the meeting notes:

Between minor or major releases, such as 2.0.x to 2.1.x or 1.9.x to 2.0.x, native-code interface compatibility is not guaranteed, even for interfaces that were previously considered FROZEN: providers of native code components, and embedders who use native-code interfaces, will at least need to recompile. We will endeavour to provide a smooth migration strategy for cases where source compatibility is not feasible, and we will also work to ensure that extension authors which rely on native components can support at least two adjacent incompatible Gecko versions in the same package.

Firefox 4 is currently targeted at Q3 of this year, though it will almost certainly slip to Q1 of 2011.

Flock yesterday launched a new beta release which includes a complete switch from its old Mozilla codebase to a new Chromium-base.

This isn’t the first time a Mozilla-based product has switched to a Webkit base – Epiphany may have been the first – but it may be the first time a product has chosen Chromium specifically. In their blog post, Clayton Stark says the following on the transition:

I also want to take this opportunity to mention Mozilla, and basically take my hat off while I’m at it. Most of the Flock team started building browsers on Mozilla in late 2004, before Firefox 1.0 was released (we built Netscape 8.x together, which was Firefox-based, before working on Flock 1.x). As we start this new chapter with Chromium, it seems important to mention that I believe chromium.org would not even exist had mozilla.org not come before it. We didn’t choose Chromium over Mozilla as much as we chose Chromium after Mozilla. It was a natural evolution. I see Mozilla as a venerable deity in the space, and I feel thankful for everything its enabled.

Still, as grateful as Flock may be, this change is part of a larger trend which has seen browsers switching to or investigating a switch to Webkit and now Chromium.

Flock created a video about their new beta that’s worth watching.

In a Bugzilla comment, Josh Aas – a Mac engineer with the Mozilla Corporation – notes that Mozilla will probably drop support for PPC builds on Mac, including those running Mac OS X 10.5. His comment:

Our strategy is to move forward with the i386/x86_64 universal binary without pulling the plug on our existing setup quite yet. At some point in the near future we’ll probably end the PPC/i386 builds and consider the i386/x86_64 builds to be our official builds for Firefox 4. We need to start work on this strategy now in order to avoid delays later.

The last Macs to ship with PPC processors were the Xserves, which were updated in December 2006. However, the Mac Pro was the last consumer machine to ship with a PPC processor. That line made the switch to Intel in August 2006.

Yesterday, Adobe released an update to their popular Flash Player, bringing the final 10.1 version to all platforms. The release was expedited to fix a critical, 0-day bug that had appeared in Flash 10.0.

Flash 10.1 included quite a bit of stability work on the part of Adobe. In the last few years, Flash has accounted for the majority of crashes in the Firefox browser, as well as other browsers. Apple has stated that Flash was the number one cause of crashes on its Mac platform. In a future version of Flash 10.1, Adobe is expected to release hardware encoding on the Mac platform, bringing its performance inline with Flash on Windows.

For those wondering, the final version of Flash 10.1 is the same as its RC7 release.