Archive for June, 2009

Embedding the Error Console in Fennec

Trying to debug problems in Fennec while running on a mobile device can be a pain. Using the JavaScript Error Console is one way you can track down problems, especially JS coding errors. Some applications, like Firefox, have a UI to launch the Error Console. Other applications don’t. You might not know this, but any Mozilla-based application automatically supports displaying and using the Error Console. Simply launch the application using the -jsconsole command line flag, and the Error Console will open.

This is all well and good on desktop devices, but some mobile devices don’t do a good job of handling multiple open windows – I’m looking at you Windows Mobile. To make it easier to view errors, we added the Error Console as a browser panel in Fennec. It’s hidden by default – you need to use about:config to display it.

  • Navigate to “about:config”
  • Set “browser.console.showInPanel” to “true”
  • Restart Fennec
  • Go to the Browser Panels to display the Error Console

It should resemble the standard Error Console. The list can be panned vertically and horizontally. The code evaluator is functional. In fact, Gavin Sharp found an easy way to mimic device window sizes when running a desktop version of Fennec. For example, enter top.resizeTo(480, 800) into the code evaluator to resize the window to match portrait mode.

Comments (3)

Fennec Linux Desktop Builds

Fennec nightly builds for Windows Mobile and Maemo have been available for some time now. Recently, we decided to make nightly desktop builds of Fennec available as well. The desktop builds can be used to test add-ons and localizations with the most up-to-date code changes.

You can find the Linux desktop builds, along with the other nightly builds, here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-trunk/

Localized versions of the Maemo and Linux desktop builds can be found here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-trunk-l10n/

Thank you L10N & Build Teams!

Comments (8)

Mobile Firefox DevCamp in Tokyo

Mozilla Japan and Clear Code held a mobile developer camp (translated) over the weekend. Fennec has been lucky to have several Japanese coders helping out for a while now. The DevCamp added even more contributors!

The DevCamp was active on IRC Friday. Bugzilla, on the other hand, was active all weekend. Many new patches were attached to bugs, including a potential fix for a crasher. A big “thanks” to everyone who attended the DevCamp.

Comments off

Fennec – Performance is the Theme

Performance is very critical in Fennec, the mobile version of Firefox. Every feature, every aspect of appearance, every piece of code… is all judged by the impact on performance. We’re lucky to have automated performance tests for Maemo and we’re close to getting the same tests working for Windows Mobile.

A few weeks ago we were making a big push toward a full CSS-based theme for Fennec. CSS means we could use physical dimensions, instead of pixels, and updating the theme for devices with different screen resolutions would be easier. Sean Martell was creating some really cool prototypes using CSS3 functionality. We landed the changes in Fennec only to discover a significant negative impact on startup (~200ms) and panning.

The CSS3 border-color styles were just too slow to render on the devices. We were actually hoping to use box-shadow because it looked much better, but the performance was a little worse. Since we were close to a Windows Mobile release, we needed to replace the new theme with something faster. We changed to a basic, flat CSS-based theme. It more than made up for the startup and panning speed problems, but didn’t look very good.

In order to make a good looking (and fast) theme we decided to switch back to images for buttons in the main browser UI. That part of the UI affects startup and panning performance more than anything else. We could still use CSS-based theme for other parts of the UI, as long as those parts do not affect startup and panning. The current theme is mostly complete and achieves the performance goals. It will be more work for us when switching between device screen resolutions, but extra work for us is better than a slower user experience.

The current theme uses a mix of pixel-based images and millimeter dimensions for everything else. It looks pretty good too.

We have some other, non-theme related, performance nuggets I’ll post about soon too.

Comments (2)

XULRunner 1.9.0.11

The newest official XULRunner has been released. XULRunner 1.9.0.11 matches the Firefox 3.0.11 release. For XULRunner developers, most of the changes in 1.9.0.11 are related to security and stability fixes. SQLite was upgraded to version 3.6.7.

Runtimes
SDKs
Source tarball

The coolest thing about this XULRunner release is how it was done. Mozilla’s Release Engineering group is now doing official XULRunner releases at the same time as Firefox releases. Previously, someone would manually file a bug, make a patch, spin the builds and push the bits. A big thank you to the release crew for adding this to their release process.

Want to get started building XULRunner applications? We have an article for that. It’s way better than the crappy XML UI framework you’re currently using :)

Comments (4)

Extension Developers – News For You

It was recently brought to our attention that a change to the context menu handling code has broken some extensions that built on the context menu. Davide Ficano found one of his extensions was broken when we replaced a property on the gContextMenu object, a helper object used to manage the context menu. The change was made in bug 449522 to accommodate new video element support.

I saw Davide’s blog post, but it sat in my many open tabs. Thankfully, Mike Kaply got my attention this morning on IRC. We filed bug 497098 and got a patch up and reviewed. Hopefully, this minimal fix will make it into the next Firefox 3.5 release candidate. SeaMonkey has a similar bug open.

This change has been in Firefox 3.5 (nee 3.1) since beta 2. We got a fix ready to go in around two days after the initial blog post mention. What could we have done to have seen this breakage months ago, when it initially landed?

UPDATE: The patch landed on trunk and the 3.5 branch. Thanks to everyone involved.

Comments (7)