FOSDEM 2009 is over. Once again, there was a lot of great stuff happening. I managed to leave the Mozilla Room once or twice to see other sessions. The Mozilla Room sessions were very good and not just because I was in two of them. There were so many people trying to get into the Mozilla Room, we had to stop people from coming in.
I posted the presentations of my Fennec and Embedding sessions. The Fennec session has a companion wiki article as well.
Paul Rouget moderated a spirited discussion on creating XUL communities. The group created a lot of good feedback for Mozilla and for themselves. I really hope we make some progress on the action items.
It’s taking a while to get nightly XULRunner 1.9.1 builds available. At this point, I’d like to have nightly XULRunner 1.9.2 builds available too. In order to help anyone that really wants to start building against XULRunner 1.9.1, I made some unofficial runtime and SDK builds.
These are unofficial (I’ve mentioned that three times) and may not be configured exactly the same as official builds. I was not able to get the Mac Universal build working. I was not able to package a Mac runtime. Macs hate me.
If you’re an extension, XUL app or plugin developer, these builds should help you move ahead with your Firefox 3.1 (Mozilla 1.9.1) development. If you find a drastic problem with the builds, please let me know (comments/email).
FennecAlpha 2 is now available for download! Desktop versions are available too (Windows, OS X, Linux). While we added some good features in this alpha, the primary focus was performance. Faster startup. Faster page loading. Faster panning and UI interactions.
Faster, faster, faster!
Madhava made a nice video showing off Alpha 2. Even from the video, anyone who tried Alpha 1 can see that Alpha 2 is noticeably faster.
I thought I’d focus a bit on what we did to squeeze more speed out of Fennec, and the Mozilla platform in general. First, a big shout out to Taras Glek for finding slow spots and filing bugs to get them fixed. Taras worked tirelessly to find as many problem areas as he could.
Panning
Alpha 1 used a two layer system to implement panning. One layer panned the UI chrome – the URLbar, the tab sidebar and the browser control sidebar. Another layer, implemented in a XBL component, panned the web content. Both layers were children of a XUL , which allowed us to position and float elements relative to each other. The “hand-off” between the two systems – when UI panning transitioned to content panning – was sloppy and chrome panning was not very smooth.
Alpha 2 combines the panning layers into a single system, still contained in a . We removed the XBL component and now chrome and content pan together as a single unit. The result is much smoother panning. Also, the chrome UI parts are now located relative to the web content much better – in Alpha 1, the sidebars panned into view sooner than they should have.
I plan to cover more details of the Fennec architecture soon.
URL Autocomplete (Awesomebar)
We found that using elements to float chrome UI over the main window was a performance problem. In fact, any XUL element that creates a native OS window under the covers slows things down. The awesomebar autocomplete list uses a . We re-wrote the autocomplete list such that it was a in the main and the results were dramatic. The list displays much faster.
URLbar
We started with XUL similar to Firefox for our URLbar. We used a for the static caption and a to allow the user to type in a new URL. The elements occupied the same space, but only one was visible at a time. We used some JS code to hide/show the appropriate element.
We found that the process of showing/hiding the elements was taking a noticeable amount of time, affecting the perceived page loading time. We ended up removing the and we just toggle readOnly on the .
Favicon Indicator
A similar situation occurred with the favicon indicator. We initially used the same holding two elements – one for the throbber and another for the website’s favicon. Again, we were showing and hiding the images depending on situation. This time it was the that was the slow down – creates a native OS window. So we removed it and page loading appeared to complete a little faster. We kept the two image elements because the load time for the swapping the favicon image with the throbber image eclipsed any benefits of removing the show/hide code.
We also restructured the way we handled favicons to wait until the page fully loaded before updating the favicon indicator. Updating the indicator immediately, while the page was still loading, just caused the page load to take longer.
Canvas and Thumbnails
For panning and zooming performance, Fennec uses a canvas element as the main display surface – not a browser element. We copy the contents of the browser to the canvas. Updating the contents of a browser to a canvas is not cheap on mobile devices. Each drawWindow call can take ~300-400ms. On the other hand, drawImage is much faster – ~100ms. In Alpha 2, we switched to use drawImage as much as we could when updating the tab thumbnails.
Alpha 2 also uses the new MozAfterPaint event to optimize all DHTML updates to the the main canvas display surface. Whenever the contents of the web page changes, for whatever reason, we only update the areas that actually changed. We don’t repaint the entire canvas.
Post-Pageload Work
Any work that occurs after the page loads is potentially bad for performance. Users like to start interacting with page content as soon as possible. We had some slow code that transformed phone numbers into links. The tel: links can allow devices to auto-dial telephone numbers. The code was optimized quite a bit in Alpha 2 (see bug).
File I/O
Various places in the platform code we found spots where file I/O was slowing Fennec down, usually on startup. As Taras said on IRC – “File I/O on the n810 is measured in milliseconds” – probably not just limited to the n810. So we tried to avoid useless I/O whenever we could. Startup improved from taking around 30 seconds (yes) for a first-time, cold start in Alpha 1 to around 7-10 seconds in Alpha 2. A warm start improved from taking around 13 seconds down to 4-5 seconds.
One spot in the Extension Manager code was checking for the existence of a file, which was never created unless you had extensions installed. That fix alone saved ~300ms during startup. XBL loading was also improved – saved 100-200ms during startup.
We still have more work to do – we are shooting for a ~3 second startup. Yes, we have already found several more changes we plan to make for the next release.
Wrapup
We made some significant improvements startup, panning and page loading. Take Fennec Alpha 2 for a spin, especially if you tried Alpha 1 and found it too slow.
The downside of the many changes we made, especially in the UI, will be extension breakage. Giorgio Maone, author of NoScript already discovered some breakage, but plans to have an updated version ready soon. Unfortunately, we will likely cause more breakage with the next release too. However, my hopes are that by soliciting feedback from the add-on developer community, we can get a stable XUL structure and JS API in place for the next release.
I decided to take a detour in my XULRunner session at MozCamp. I have done several XULRunner talks over the last few years. I usually focus on the functionality built into the platform and discuss the benefits of using Mozilla technologies to develop applications.
This crowd was very Mozilla savvy and many had at least experimented with building XULRunner applications. So, instead of my normal slide deck, I went with a “walk-through” of using the Mozilla build system to create a XULRunner application. I did the same with setting up an auto-updating XULRunner application. I think the Mozilla build system is something any XULRunner developer should learn and setting up auto-updating always seems to frustrate developers.
The talk went very well. Thanks to Robert Kaiser for helping me fill in some blanks. We had some good discussion and I could have spent a lot more time covering some of the smaller details. I think I might look into expanding this “walk-through” format.
Another topic we talked about was the potential of XULRunner on mobile devices. Many developers are excited to see XULRunner become available for mobile platforms. The ability to move XUL applications from desktops to mobile devices is fairly powerful. Fennec, for example, runs just fine on any supported XULRunner platform – without any changes.
One of the opportunities I had at MozCamp was to get caught up on the stuff happening in Thunderbird & Calendar. They have a goldmine of great data, functionality and UX possibilities. During some of the sessions and a small ad-hoc discussion, the use of HTML in XUL to create compelling, interesting and useful user interfaces came up. Thunderbird 3 will be using HTML to enhance to appearance and functionality of message display. Calendar might be using HTML to do the same for displaying tasks, IIRC. The examples I saw looked great.
I got the feeling that the designers and developers thought that using so much HTML in XUL was, in some way, anti-XUL. NO WAY! It’s my opinion that using HTML in this way – enhancing a user interface – shows the power of XUL. The ability to seamlessly mix different markup languages is quite impressive. How many other UI markup languages can do that?
The use of HTML, SVG and specifically, in XUL is not new. You’ll find many examples of add-ons and applications that go beyond XUL to create elements of the UI. XUL itself uses HTML as a foundation for implementing widgets.
Here are some examples from previous posts on using HTML, SVG and in XUL. Start spicing up your XUL UI today.
I am headed to Barcelona to take part in Mozilla Europe’s MozCamp 2008 conference. I’ll be presenting sessions on XULRunner, Fennec Add-ons & Embedding Gecko. If you’re interested in any of these sessions and have topics you’d like to see covered, let me know. Commenting here or adding items to the wiki pages are goods ways to do that.
I also plan to hang around the Prism session, presented by Matt Gertner. Prism has some cool features brewing. I hope we get a new release (with samples) out soon.
XUL Explorer is a small tool I started a while ago to allow me to quickly create and preview short snippets of XUL. At the same time, I used the process of building XUL Explorer as a use case to help me discover and learn various parts of the Mozilla platform. With the help of some great contributors, it’s been extended beyond simply previewing XUL.
As a tool, XUL Explorer has been serving me well, but I have been wanting to refine it as an application. As I continue to discover how to use the Mozilla platform to it’s fullest, I want to push those concepts back into XUL Explorer. Therefore, I give you XUL Explorer 1.0a1pre, with the following changes:
Proper build system – Project is now using the Mozilla build system which makes building on all three platforms a breeze.
Auto-update system – The built-in Mozilla auto-update mechanism has been enabled. The application will periodically check for updates on my server and download/apply them as needed.
Updated XULRunner – The bundled XULRunner runtime is now based on the 1.9.0.x branch (same as Firefox 3.0.x). Now you can play with the new XUL elements and platform features.
Updated DOM Inspector and Venkman – XUL Explorer now bundles the newest versions (from the 1.9.0.x branch) of these extensions. Using the Mozilla build system makes this simple too
A couple small bug fixes and UI tweaks
With the build system changes, I can finally start taking localizations in a manageable fashion. If anyone has a translation you’d like me to add, file a bug here.
Install Windows, OS X (Intel) and Linux versions from here.
A big thanks to Dave Townsend and Matt Gertner for providing some great samples and documentation. Also, the work I have been doing on Prism and Fennec has been helping me expand my knowledge of the Mozilla platform too.
The newest official XULRunner has been released. XULRunner 1.9.0.3 matches the Firefox 3.0.3 release. Firefox 3.0.2 was out for a very short time, so we skipped it for XULRunner.
Nightly Maemo builds of XULRunner are in the final stages. A tinderbox page and FTP folder are in progress. Windows Mobile builds of XULRunner have progressed to the point where it can be built directly from the main Mozilla source tree. However, there’s a bit more work needed before we can start creating nightly builds.
In HTML you can use a DIV as a container and when the DIV changes size, the contents will wrap or adjust the layout. This does not happen with XUL BOX (or HBOX and VBOX) by default. However, you can easily add this capability with a style change. Make the BOX style="display: block" and the wrapping behavior will occur when the box is resized:
If you put IMAGE in the contents, you should probably add align="start" attribute to the box. This keeps the image from stretching inside the box.
This question keeps popping up on IRC, so I added a code snippet to MDC. Hopefully, it will reduce the number of times Mook, Mossop and Neil have to answer the question. (At least they have something to point to now)
As you mighthaveheard, Mozilla is working on a mobile browser (codenamed Fennec). If you are interested in Mozilla and mobile, I’d encourage you to start following the project. Besides the just plain awesome idea of a Firefox browser running on mobile devices, there are other reasons I like the project.
Fennec is using XULRunner to power the application. The same XULRunner that is already available for Windows, Mac and Linux. Longtime XULRunner fans should be happy to hear of a Mozilla project building directly on XULRunner. Besides the additional focus, look for improvements to the Mozilla platform related to mobile devices. Mozilla prides itself on building applications that look and feel native, so we shouldn’t be surprised to see new support and APIs for mobile devices and applications.
Getting XULRunner ported to mobile platforms has the obvious benefit of allowing anyone to build mobile applications using the Mozilla platform. So, if you have experience building XULRunner applications on the desktop, get ready to start exploring the world of mobile development! So if you have a supported device, start hacking! Antonio Gomes has already been doing some great work porting Prism to Maemo.
