Firefox running on the Palm Pre (mostly)

One of the first things I did when I moved to the U.S. was to get myself a smartphone, and that phone was the Palm Pre. I’ve always thought it was way ahead of its competition in terms of the potential of its potential capabilities and platform. Sadly I think it is let down some by build quality and hardware issues, but I still love it as a phone and really hope that if Palm get bought they’ll continue work on it and develop a better 2nd gen version.

The browser on the Pre is pretty limited. I won’t deny it is nice to use but I miss things like the awesome bar from Firefox and so ever since Palm announced the PDK (a development kit for developing native apps for the Pre) I’d been wondering how much work it would take to get Firefox ported to the Pre. It turns out not a lot, at least so far. Unless you’re actually interested in the details of what I did you may just want to skip to the end of this post, or just move on to something more interesting.

Getting started

Spidermonkey shell running on a Palm PreI had spoken to Vlad Vukicevic a while ago. He had gone through the process of porting Firefox for Android and he told me the steps to take were pretty straightforward. You basically have to get the core pieces (NSPR, Spidermonkey, XPCOM) compiling for the platform, then you need to write what is called the widget code and deals with displaying graphics on the screen and receiving input events from the device.

On Friday evening I sat down and for the first time seriously looked through the PDK documentation, which is reasonably good. Perhaps not surprisingly I quickly realised that the core libraries that are available in the device are basically the same as those available in Android’s NDK. Added to that I had read that Vlad was simply using OpenGL to draw to the screen, and the PDK provided OpenGL too. So ignoring input events it looked likely that I could just use a lot of the code they had used for the Android port to make things work on the Pre.

This turned out to be pretty much true. Getting Firefox compiling for the Pre took a little under half a day, mostly because of some strange build config problems that I still haven’t properly resolved and have just hacked around for now. The first thing I tried was copying the JS shell over to the device and running it. Aside from some library loading issues it basically worked first time and I could run simple JavaScript code.

Debugging is hell

Firefox running on a Palm PreGetting it to render a UI was slightly more involved. Writing the actual code to do it was simple and maybe took me an hour or two (mostly because I was just copying and adapting the Android code). The thing that took the long time (around 8 hours) was trying to find the one tiny line of code that I missed and was causing Firefox to crash shortly after startup. Firefox’s code is pretty complex, and while you can get so far with adding lots of logging there was just too much going on to find this bug this way so debugging with gdb is generally the solution. Apparently in the Windows version of the PDK Palm include an Eclipse plugin that allow you to remotely debug apps running on the device. Nothing like that seems to be included in the OSX version so I ended up having to find and build a gdb that would debug ARM code (Palm, please just include this in the next OSX PDK) and then set up gdbserver on the device and connect to it. Perhaps because of my self-built GDB symbol tables for shared libraries simply didn’t work right. For some reason my gdb never attempted to load symbols for libraries that the device loaded, I ended up having to use a horrific hack to force it to load them. It paid off though, 5 minutes after I got the symbols to load I found my problem and had Firefox running without crashing, just not displaying much.

Turns out it was trying to but my first attempt to read events from WebOS were blocking the load of images and XUL for the UI. I discovered this completely by accident when I got frustrated with the blank screen and tapped it a few times, moments later the Firefox UI appeared in all its squished glory. I hope you’re all as astounded as I was that it appeared basically pixel perfect the first time around. Credit should go entirely to the guys working on the Android port for that really.

Hot tip for new widget developers, when nsBaseAppShell calls your widget’s ProcessNextNativeEvent and tells it it may block for the next available event, don’t block.

What next?

Once the UI was visible it wasn’t very difficult to start pushing mouse (finger) and keyboard events through from WebOS to Gecko. All in all getting to that point took about two days though probably would have been half that if debugging had worked straight off. There are now a bunch of smallish issues related to mouse and keyboard events that need fixing and should be pretty simple to handle. The repainting code is also very inefficient as it redraws the entire screen in response to a single pixel changing. I’d also like to switch to the Fennec UI. The Firefox UI is good for testing as it is pretty complex and you can quickly see if there are any problems or not, but the Fennec UI will make far better use of the available screen space.

There are some larger issues though that would need to be fixed before I’d consider making this available to others. In particular right now it will randomly hang the entire phone. Once that happens you have to pull the battery to recover it and I’ve lost some settings on my phone because of that. I have no way to debug that right now since once it happens there is no way to see what is going on on the device (maybe someone out there has some suggestions on how to figure this out). As well as that the build system is pretty much hacked to work on my computer. I think there is just one small thing I’m not understanding there and then I can fix that, but finding people knowledgeable enough about Mozilla’s build system to help me figure it out is difficult. Once I’ve ironed out these issues I’ll make the code available, maybe even some test builds and hopefully some other developers might be interested in helping me tackle some of the remaining problems.

Perhaps it goes without saying but I am only working on this in my spare time, not as part of any official Mozilla drive to target the Palm devices. I don’t know if it will ever get to the point where Mozilla would include it as one of the official Firefox Mobile versions, but that isn’t all that much of a big deal. Assuming the main code that deals with the Pre’s hardware and platform is sound, the code should just continue to work whatever they do with the Fennec code and I know the mobile team will always be helpful to talk about how other devices work to help me figure out what the Palm code should do.

Update: Alpha builds of PreFox, a web browser based on the Mozilla source code are now available for testing.

37 thoughts on “Firefox running on the Palm Pre (mostly)”

  1. “I have no way to debug that right now since once it happens there is no way to see what is going on on the device (maybe someone out there has some suggestions on how to figure this out)”

    Silly suggestion, I assume you have probably already thought of this or for some reason why this wouldn’t work, but maybe setup an ssh terminal and remote in when it hangs? See if its just the webos ui hanging or the whole system? http://www.webos-internals.org/wiki/OpenSSH_Install

    1. When I say that the phone hangs I mean it really hangs, everything seems to stop. Existing ssh connections to the phone time out and new connections cannot be established. Touching the screen or keys or anything does nothing, the display is frozen showing what was there.

      I guess I haven’t tried leaving it for an hour to see if it recovers but it seems unlikely. My best guess right now is that I’m seeing a kernel panic which I might be able to spot in the syslog if that remains around after pulling the battery.

      1. Well at least what I can spot in the logs are lots of messages like this. I’m not really much of a low-level guy so maybe someone knows what these signify and if it is bad or ignorable:

        2010-04-13T05:09:47.497467Z [1466] palm-webos-device kern.warning kernel: [ 1466.780000] Alignment trap: firefox-bin (2439) PC=0x3648e0a0 Instr=0xe5933000 Address=0x9ef629a3 FSR 0x001

        1. Try running through the various xpcom and xptc / xpconnect tests? Some of them may be broken on m-c because they don’t run on the tinderboxen (and they require non-libxul builds). Sorry I wasn’t much help on your -lpthreads problem; I haven’t seen that, probably because I mostly cross compile to various Windows targets.

  2. The hangs are probably udelay not delaying long enough in arch/arm/mach-omap3pe/prcm_pwr.c (read it and… shudder). What I did was:

    mason~/build/hardware/uber-kernel-pre/build/src-1.4.1-2/linux-2.6.24/arch/arm/mach-omap3pe$ diff prcm_pwr.c.orig.prtest prcm_pwr.c
    1175c1175
    udelay(2);
    1708c1708
    udelay(30);
    mason~/build/hardware/uber-kernel-pre/build/src-1.4.1-2/linux-2.6.24/arch/arm/mach-omap3pe$

    Needs more testing though. http://forums.precentral.net/web-os-development/241483-1-4-1-kernel-destroy-your-phone.html has links to the kernel (also 800MHz, preempt, anticipatory scheduler, some other fun stuff).

    Cheers, Steve

  3. I’m very excited to see someone pushing the PDK as hard as this!

    We do ship GDB with the CodeSourcery tools on Windows… it didn’t get built for the OS X toolset, but the engineers who are building the next version know it’s needed.

    Be aware that when we ship the PDK support libraries with an OS release, there will be some sandboxing. I don’t think it will directly affect this port, but it might limit the access to system libraries. I’m trying to make sure we include as much as possible with that.

    You should be able to create a swap file in /media/internal and do a swapon command to add some swap space if needed while debugging. We also support NFS mounting from the device if you want to pull in the source code from your main system while debugging on device.

    Feel free to ask questions over at the forums on developer.palm.com… I check there a few times a day and so do a lot other Palm engineers.

    1. Thanks Ben, good to hear that GDB is coming for OSX. I believe that it’s pretty light in terms of what libraries Firefox links too, pthread, dl and m are the main ones other than the basic system libraries like c and stdc++.

      I guess the other thing you might sandbox is files on the system. Right now I have Firefox loading fonts from out of /usr/share/fonts. If access to that went away it may be possible to just bundle some fonts with the Firefox package, but that wouldn’t be ideal.

  4. Thanks! very excited. Im not coding expert so can’t help that. Just want to show my gratitude for your work.

    I hope people donate, i know I would.

  5. Please continue to update us on this! I would love to have firefox working in any sort of way. I couldn’t care about UI much, I just want the power of FF

Comments are closed.