As of today’s Nightly, Asynchronous Plugin
Initialization is available for testing. It is deactivated by default, so in
order to try it out you will need to navigate to about:config and toggle the
dom.ipc.plugins.asyncInit preference to true.
If you experience any problems, please file a bug that blocks bug 1116806.
Happy New Year!
Today’s Nightly 34 build includes the work I did for bug 286355: a profile unlocker for our Windows users. This should be very helpful to those users whose workflow is interrupted by a Firefox instance that cannot start because a previous Firefox instance has not finished shutting down.
Firefox 34 users running Windows Vista or newer will now be presented with this dialog box:
Clicking “Close Firefox” will terminate that previous instance and proceed with starting your new Firefox instance.
Unfortunately this feature is not available to Windows XP users. To support this feature on Windows XP we would need to call undocumented API functions. I prefer to avoid calling undocumented APIs when writing production software due to the potential stability and compatibility issues that can arise from doing so.
While this feature adds some convenience to an otherwise annoying issue, please be assured that the Desktop Performance Team will continue to investigate and fix the root causes of long shutdowns so that a profile unlocker hopefully becomes unnecessary.
Something that I’ve been noticing on numerous social media and discussion forum sites is that whenever Firefox comes up, inevitably there are comments in those threads about Firefox performance. Given my role at Mozilla, these comments are of particular interest to me.
The reaction to roc’s recent blog post has motivated me enough to respond to a specific subset of comments. These comments all exhibit a certain pattern: their authors are experiencing problems with Firefox, they are very dissatisfied, but they are not discussing them in a way that is actionable by Mozilla.
Mozilla encourages our contributors to run prerelease versions of Firefox, especially Nightly builds. This allows us to do some good old-fashioned dogfooding during the development of a Firefox release.
We also have many tools that run as part of our continuous integration infrastructure. Valgrind, Address Sanitizer, Leak Sanitizer, reference count tracking, deadlock detection, assertions, Talos performance tests, and xperf are some of the various tools that we apply to our builds. I do not claim that this list is exhaustive! :-)
We use numerous technologies to discover problems that occur while running on our users’ computers. We have a crash reporter that (with the user’s consent) reports data about the crash. We have Firefox Health Report and Telemetry that, when consented to, send us useful information for discovering problems.
Our ability to analyze crash report/FHR/telemetry data is limited to those users who consent to share it with us. As much as I am proud of the fact that we respect the privacy of our users, this means that we only receive data from a fraction of them; many users who are experiencing problems are not included in this data.
Despite the fact that we have all of these wonderful tools to help us deliver quality releases, the fact is that they cannot exhaustively catch every possible bug that is encountered out in the wild. There are too many combinations of extensions and configurations out there to possibly allow us to catch everything before release.
That’s where you, our users, come in!
Reddit, Hacker News, Slashdot and other similar sites are fantastic for ranting. I should know — I do it with the best of them! Having said that, they are also terrible for the purposes of bug reporting!
As users it’s easy for us to assume that somebody else will encounter our problems and report them. Unfortunately that is not always the case, especially with a browser that is as configurable as Firefox.
If you are experiencing a bug, the best way to ensure that something can be done about your bug is to report it in Bugzilla. This might seem a little bit intimidating for somebody who is new to bug reporting, but I assure you, Mozillians are really nice! As long as you follow the etiquette guidelines, you’ll be fine! One suggestion though: try to follow our bug writing guidelines. Doing so will maximize the likelihood of a contributor being able to reproduce your problem. In addition to these suggestions for bug filing, I also suggest including certain types of data for specific types of problems:
If you’re experiencing problems with Firefox’s memory use, open a tab, and
point your browser to about:memory. This nifty feature provides a breakdown
of Firefox memory consumption. Save that report and attach it to the bug that
you’ve filed.
If you want report a problem with Firefox being slow and/or mysteriously consuming large amounts of CPU time, the best way to help us is is to include data that has been generated by the Gecko Profiler. [This data is referred to as a “profile,” but please do not confuse it with the user profile that stores your settings and browser history — they are different things with the same name.] This tool tracks how Firefox uses your CPU over time. If you are able to attach a profile that was taken during a period of time where Firefox was running poorly, it will help us understand what exactly Firefox was doing. Unfortunately this is tool requires a bit of technical savvy, but attaching the URL of an uploaded profile to your performance bug can be very helpful.
As you can see in our crash report data, crashes reported to Mozilla are ranked by frequency. As you might expect, this implies that it’s often the squeaky wheels that get the grease.
If you have an easily reproducable crash and you are sending your reports to
Mozilla, you can help us by pointing Firefox to about:crashes. This page lists
all of the crash reports that have been generated on your computer. If the crash
that you are experiencing isn’t on our list of top crashers, you can still help
us to fix it: filing a bug that includes multiple crash report URLs from your
about:crashes screen will help tremendously.
I’d suggest reporting your problem over at webcompat.com. Volunteers will review your report and determine whether your problem is caused by the website or by Firefox, and file a bug with the appropriate entity.
Send us feedback!
If there is one idea that you can take away from this post (a TL;DR, if you will), it is this: Mozilla cannot fix 100% of the bugs that we do not know about.
Taking an active role in the Mozilla community by reporting your issues through the proper channels is the best way to ensure that your problems can be fixed.
EDIT: To be clear: What I am suggesting is that users who are enthusiastic enough to post a comment to Hacker News (for example) should also be savvy enough to be able to file a proper bug report. Please do not misconstrue this post as a demand that novice users start filing bugs.
EDIT August 15, 2014: Nick Nethercote just blogged about a tricky memory bug that couldn’t have been diagnosed without the help of a Redditor whose complaint we steered to Bugzilla.
EDIT August 23, 2014: Wow, this has blown up. More edits to update this post with additional information in repose to some of the questions posted in the comments. Thanks for reading!
EDIT March 30, 2021: I updated various links that had rotted since 2014.