Tag: firefox

Blog entries related to Mozilla Firefox

Building Firefox With clang-cl: A Status Update

Last June, I wrote about enabling building Firefox with clang-cl.  We didn’t get these builds up on the infrastructure and things regressed on both the Mozilla and LLVM side, and we got to a state where clang-cl either wouldn’t compile

Posted in Blog Tagged with: , ,

Tab audio indicators and muting in Firefox Nightly

Sometimes when you have several tabs open, and one of them starts to make some noise, you may wonder where the noise is coming from.  Other times, you may want to quickly mute a tab without figuring out if the

Posted in Blog Tagged with: ,

Intercepting beacons through service workers

Beacons are a way to send asynchronous pings to a server for the purposes such as logging and analytics.  The API itself doesn’t give you a way to get notified when the ping has been successfully sent, which is intentional

Posted in Blog Tagged with: , ,

Building Firefox on Windows with clang-cl

Over the past three weeks or so, Jeff Muizelaar and I started to investigate what it would take for us to be able to use clang-cl to build Firefox on Windows, and I’m really excited to report that as of

Posted in Blog Tagged with: , ,

Per-window private browsing ready for testing now!

One of the most often requested features in the private browsing support for Firefox has been the ability to open a private window without needing to close the entire session. Over the past 19 months, we have been working on

Posted in Blog Tagged with: , , ,

Firefox 15: updates are now more silent

Firefox 15 is released on August 28th.  Among many new features implemented in this release is background updates.  This feature allows Firefox to download the update in the background, apply it alongside with the existing installation, and keep the updated version around so that it can quickly switch to it the next time that the browser starts up.  This effectively eliminates the update progress dialog that appears when you start Firefox after it has downloaded an update:

I previously wrote about this project.  You can see that post for more technical details.  This feature landed a while ago on the Nightly channel, and we soon discovered a few issues which we addressed in time for this to get uplifted and enabled on the Aurora channel.  Luckily no new issues were discovered with this feature as it rode the train to get on the Beta channel, and will get in the hands of all of Firefox users on Windows, Mac and Linux as part of the Firefox 15 release.

This was one of the scariest projects that I’ve ever worked on, since messing something up in the updater component could have catastrophic consequences in case it prevents users from being able to update to newer Firefox revisions.  I’m happy that the results of this project will soon get in the hands of millions of Firefox users, and I would like to thank Robert Strong, Brian Bondy, and the wonderful members of our Release Engineering (in particular, Ben Hearsum and Chris AtLee) and QA teams (in particular, Vlad Ghetiu) who helped me a lot along the way.  You guys rock, for being extremely helpful, and for making this large project possible!

Posted in Blog Tagged with: ,

Updating Firefox in the Background

The dialog below should look familiar. It displays while Firefox completes the update process after a new version is installed and the browser is restarted.

Firefox Update Dialog

In order to update itself, Firefox first starts to download an update in the background. When the update is downloaded, Firefox stages it in a directory ready to be applied. The next time that Firefox is about to start up, it checks out the staging directory. If an update ready to be applied is found, Firefox launches the updater program, and applies the update on top of the existing installation (showing that progress bar as it’s doing its job). When the update process is finished, the updater program restarts Firefox. All of this happens as you’re waiting for your browser to start up in order to do what you wanted to do. This is clearly less than ideal.

For the past few weeks, I have been working on a project to improve this process. The goal of my project is to minimize the amount of time it takes for Firefox to launch after downloading an update. The technical details of how I’m fixing this problem can be found this document. Here’s a short version of how the fix works. When Firefox finishes downloading an update, it launches the updater application in the background without displaying any UI, and applies the update in a new directory that is completely separate from the existing installation directory. Instead of staging the update itself, an entire updated version of Firefox is staged. The next time that Firefox starts up, the existing installation is swapped with the new updated installation which is ready to be used. In this scenario, you likely won’t notice that Firefox has applied an update as no UI is shown.

Now, the reason that this approach fixes the problem is that swapping the directories, unlike the actual process of applying the update, is really fast. We are effectively moving the cost of applying the update to right after the update has been downloaded while the browser is running. This leaves only the really fast copy operation to be performed the next time that the browser starts up.

I have some experimental builds with this feature ready in a temporary channel called Ash. The implementation is now at a stage where it can benefit testing from the community. You can download the latest builds here. I will trigger a few nightly builds on this branch every day so that you would get updates if you’re running an Ash build.

In order to help with testing this new update process, all you need to do is to download the latest build from Ash, then wait a few hours so that a new nightly build becomes available, and then update to that build. Updating can be triggered manually by opening the About dialog, or by the background update checker if you leave the build running for a few hours. If everything works correctly, when you restart Firefox, you should get a new build without seeing any progress bar as Firefox is starting up. In order to verify that you have indeed been updated to a new build, you can go to about:buildconfig, copy its contents, and then compare it with the contents of about:buildconfig when Firefox starts up after an update.

It would be extremely useful if you can test this with different types of security and anti-virus software running. If you observe any problems or warning, or if you see that the update did not change the contents of about:buildconfig, then please let me know so that I can try to fix those problems.

For people who are curious to see the code, I’m doing my development on this branch, and I’m regularly posting patches on bug 307181.

Please note that this is still in the testing stage, and at this point, we’re not quite sure which version of Firefox this will land in (we’re working to land it as soon as is safely possible). No matter which version of Firefox includes this feature for the first time, we believe that this will be a very positive change in making the Firefox update experience more streamlined for all of our users.

Posted in Blog Tagged with: , ,

Building Firefox with Address Sanitizer

Address Sanitizer is a new project based on clang which aims to provide relatively cheap memory access checking.  It is capable of detecting errors such as out-of-bounds access or use-after-free at runtime.  Although its functionality is a subset of what Valgrind supports, running applications built with Address Sanitizer is noticeably faster than running them under Valgrind, which can simplify the testing process.

I recently got a build of Firefox with Address Sanitizer working.  Getting these builds in relatively simple.  Firstly, you should build Address Sanizer yourself.  Then, you can use a mozconfig like this:

export CC=/path/to/address-sanitizer/asan_clang_Linux/bin/clang
export CXX=/path/to/address-sanitizer/asan_clang_Linux/bin/clang++

export CFLAGS='-fasan -Dxmalloc=myxmalloc'
export CXXFLAGS='-fasan -Dxmalloc=myxmalloc'
export LDFLAGS=-ldl

. $topsrcdir/browser/config/mozconfig
mk_add_options [email protected]@/objdir-ff-asan
mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-application=browser
ac_add_options --enable-debug
ac_add_options --disable-optimize
ac_add_options --disable-jemalloc
ac_add_options --disable-crashreporter

Once your mozconfig is set up, just build and run Firefox as you normally would.  I have not yet found any memory safety issues in Firefox using Address Sanitizer, but it’s not really surprising, since I mostly attempted to run our unit tests with this build, but the build is fast enough that you can even use it as your main browser.  If you do see an issue, please file a bug.

Posted in Blog Tagged with: , ,

Running Firefox tests with extensions installed

When debugging a test, I’ve sometimes found it useful to have access to an extension such as DOM Inspector or Firebug to debug what’s going on with the test.  In the past, you could do this by a bunch of hacks to make sure that you get the extension inside the test profile folder in time so that the test harness doesn’t delete it for you.  But last week I landed a patch which enables you to do this more efficiently.  Here’s how the new setup works:

  1. You should download the extension’s XPI into your current directory.
  2. You should rename it into {addon-ID}.xpi, where addon-ID is the ID of the extension as specified in its install.rdf file.
  3. You should pass the name of the new XPI file to the –install-extension flag which runtests.py and runreftest.py scripts now accept.

For example, if you want to have Firebug when running the mochitest suite, here’s how you should start the suite:

python objdir/_tests/testing/mochitest/runtests.py --install-extension=firebug\@software.joehewitt.com.xpi

Happy debugging!

Posted in Blog Tagged with: , ,

Important changes to the Firefox 4 spell checker

Update: We had to pull these changes out of Firefox 4 because of some regressions that they caused.  We will revisit this issue after Firefox 4, and will hopefully deliver this set of fixes in the next version of Firefox.


I landed a patch today which changes the Firefox 4 built-in spell checker in two important ways:

  • Firefox 4 will be able to correctly spell check words containing hyphens, such as the English word "scot-free".
  • Firefox 4 will be able to correctly spell check words up to 130 letters long.

Here is the slightly longer version of what changed.  Before this change, when Firefox saw a word such as "scot-free", it would break it into two words, "scot" and "free", and pass each of them to Hunspell (which is the spell checking engine we use) to see if they are correctly spelled or not.  So, even though the word was correctly spelled, Hunspell would not have any way to know that, because all it saw was Firefox asking it whether "scot" is correctly spelled, and whether "free" is correctly spelled.  The result was that "scot" was underlined as incorrectly spelled.

After this change, Firefox would pass the entire word, "scot-free" to Hunspell, which would enable Hunspell to recognize the whole word, and make the correct decision about its spelling.  This is especially important for the languages which use the hyphen character as part of the non-compound words frequently.

Also, previously, Firefox would automatically mark any word with more than 64 letters as being incorrectly spelled.  This is a problem for languages which tend to have words much longer than that, such as German and Swedish, to name a few.  The new limit is 130 letters.  This new limit might also not be enough for some words in some languages.  We plan to remove this limit entirely in future Firefox versions.

If you’re a localizer, or a dictionary author, there shouldn’t be any need for you to change the dictionary files for your language.  However, it would be great if you can test Firefox 4 nightlies starting from tomorrow with your languages to verify that it correctly recognizes long words in your language, or those words which have a hyphen in them (and are not compound words).  Keep in mind that these changes will only affect your language if the dictionary is capable of recognizing those words.  If you see any issues with this, please file a bug to let us know.

For the gory details, the curious reader can read bug 355178.

Posted in Blog Tagged with: , ,