ZenLinux Blog

Mozilla’s Firefox web browser and Thunderbird e-mail clients have a little-known feature known as “Profiles.” Profiles allow you to create fully separate instances of these applications, each with their own customized config preferences and extensions.

I make heavy use of this feature to create separate Firefox profiles for my personal everyday web browser, work web browser, web development browser, etc. With Thunderbird, I use profiles to separate my personal vs. work email.

From the command line, invoking firefox or thunderbird with the -P option will bring up a dialog box, allowing you to chose between your existing profiles, or create/rename/delete profiles:

If you haven’t created any new profiles, you’ll be using a profile named default. On my Ubuntu systems, each of these profiles will be stored under your ~/.mozilla/firefox/ directory (for Firefox) or ~/.thunderbird/ directory (for Thunderbird).

If you want to be able to easily launch these profiles from the GNOME Shell GUI rather than the command line, you can create custom launchers for each profile. I typically do this and choose different icons for each profile to visually tell them apart. To do this, create a .desktop file within your ~/.local/share/applications/ directory. I typically name these files firefox-<profile-name>.desktop. Here’s an example of one:

[Desktop Entry]
Version=1.0
Name=Firefox (WebDev)
Exec=firefox -P webdev -no-remote --class FirefoxWebDev
Comment=firefox
Terminal=false
Icon=/usr/share/icons/oxygen/base/128x128/categories/applications-development-web.png
Type=Application
StartupWMClass=FirefoxWebDev

By default, the Icon setting will search for an icon file (e.g, .svg or .png file) from your current theme within your /usr/share/icons/ directory. Specify an absolute path to the icon file and include its filename extension if you want to use an icon that’s not in your current theme. You can also create custom icons and drop them in your ~/.local/share/icons/ directory.

Note that on the Exec line I’m also starting firefox with two additional options, -no-remote and --class. The -no-remote option prevents conflicts with other instances of Firefox that are running. The --class option specifies a window manager class, which you’ll also set for the StartupWMClass option. You can set this value to any string you like, but it must be unique (i.e, don’t re-use it in another .desktop launcher config).

If you don’t set a custom window manager class, all of your running profiles will be grouped together under the same icon in the GNOME Shell panel. That last subtlety has been an annoyance I’ve wanted to fix for a long time, and learning about it is what prompted me to write this post to share.

References: Mozilla docs on using the profile manager, AskUbuntu post on setting the window manager class

With the release of Firefox v3.0.4 the other day, I was hoping to see the inclusion of the mjpeg bug fix. Unfortunately it was not included with this release, but the bug report mentions that it is being planned for inclusion in the next release, v3.0.5. In the meantime I guess we’ll have to do another patch and compile.

I’ve spent the better part of this week doing battle with a pesky problem in Firefox v3. The bug report on Mozilla’s bug tracking system (along with a patch to fix it) can be found here if you’d like to read all the gory details.

The product I’m putting the finishing touches on at work is a touchscreen-based appliance that can, among other things, display video streams from IP cameras. The lowest common denominator for IP cameras it supports is the motion JPEG protocol, so early on in the project (many months ago) we did some testing and found that Firefox readily supports displaying these streams, and that we could also use a video player plugin for better system performance. Sounds like an easy feature to add, yes?

Nope! It turns out that the bug I referenced above means that once you display an MJPEG stream, it never stops running. If you browse away from the stream you still take a performance hit, and Firefox eats up the CPU and network bandwidth resources as if the stream was still being displayed. This became a critical problem on an embedded platform that needed to display up to four IP camera streams at the same time. Additionally, the camera streams are not the focus of the product (its primary purpose is to control multiroom audio systems).

So onto “Plan B” – the mplayer video plugin for Firefox. As a bonus, this plugin makes use of hardware video acceleration to display streams, resulting in significantly lower CPU utilization. Have we found a winner? No, again. The plugin did its job well, until you went to unload it from the page. This process turns out to take an indeterminate amount of time due to various complex interactions between the plugin and the independent mplayer process that also needs to be shut down. The delay would amount to several seconds regularly – unacceptable for the product’s requirements. Various aggressive methods of killing the plugin to avoid the delay only resulted in killing Firefox along with it. And through communication with one of the open source developers of the mplayer plugin, we confirmed that this was a inherent design problem that could not be overcome.

So what now? All I can say is we are very, very lucky that the Mozilla team fixed this bug. Although it is not yet released into the mainline Firefox, I was able to apply the patch cleanly to the sources and compile a custom Firefox that meets our needs.

It’s been a long week, but in the end I am still grateful that we’re using open source software as our technology foundation. It may have its problems, but if you put some effort into searching through the infrastructure that’s publicly available on the web (i.e, bug tracking sites and mailing lists) you can usually understand and find the solutions to your problems.