Faster and snappier searches now in Firefox Aurora

In case you haven’t noticed yet, Firefox Aurora contains some great speed ups when searching from the location bar. For far too long, searches that consisted of a single-word or arithmetic expressions would either result in errors or long delays before a search results page was presented.

This has all changed starting in Firefox Aurora. Take for example, a search for “867-5309”:

Previously when a single word was typed in to the location bar and Enter was pressed (or the Go button clicked), Firefox would look for a website at http://867-5309/. After the lookup timed out, Firefox would redirect to a search for “867-5309“. If the hyphen was removed and “8675309” was entered, Firefox would immediately go to an error page saying that it was unable to connect to the server at 8675309.

Some people may have become accustomed to placing a `?` at the beginning of the location bar to subvert this behavior. With the new Firefox Aurora, this is no longer necessary.

Slow and broken search behavior seen in Firefox 32 and older

Now, in both of these cases Firefox will kick off the search request immediately. In the background, Firefox will look for locally-hosted sites that have a hostname matching the value that was typed in. Most people will see search results on average 5 seconds quicker!

In cases where there is a potential match, Firefox will show a notification bar asking if the locally-hosted site was the intended destination. Clicking “Yes, take me to 8675309” will navigate to the matched site and whitelist it for future.

Screenshot of new behavior coming in Firefox 33

If you’d like to proactively whitelist a site, you can go to about:config and create a new Boolean pref with the name of `browser.fixup.domainwhitelist.` followed by the single word that you would like whitelisted. Set the pref to true, and the search will be skipped. localhost is already whitelisted.

Firefox continues to gain speed, customizability, and security with each release. This feature will find its way to the Release population with Firefox 33. In the meantime, you can install Firefox Aurora or Firefox Nightly and begin using it today.

There are two minor cases left to fix:

• Queries that end with a period still fail. This is in the process of being fixed and can be tracked at bug 1042519.
• Queries containing a period in the middle also fail. This is not currently being worked on, but is tracked at bug 494092.

Firefox Performance/Snappy Work Week: Warsaw edition

Last week I was with the “Snappy” team in Warsaw, Poland working out of the Noa Cowork space.

While there I got to meet more people that I have talked with online before and build stronger relationships. I also learnt a lot from Bas Schouten and Benoit Girard as they showed me the tools that they have been working on recently.

Bas works from Holland and is on the Graphics team. Firefox’ tab strip and toolbar area is one of our biggest areas of concern when it comes to snappiness. It is probably the most visible part of the browser that users attribute to responsiveness. Users may blame slow webpages on the website authors, but slow browser chrome will most definitely be blamed on Firefox itself.

Bas wrote a tool that records all of the drawing commands that the graphics system performs. These commands are then saved out to a file and his program can replay them step-by-step. This tool is really great at finding problematic drawing sequences.

In a couple cases, Firefox reaches near completion of drawing the navigation toolbar, and then decides to start the process over. One metric showed there were around 95% redundant drawing commands due to issues like this. While this tool is great at finding these issues, it’s not perfect. There is still a lot of work to do to find the relationship between our CSS, markup, and graphics system to determine which area is causing the issues and how we can fix them.

It should be noted the 95% redundancies seen is partially due to some aspects of the way we are currently using the drawing architecture. It does not mean 95% of performance is wasted. The practical speedup that could be achieved by removing redundancy is estimated to be between 10-20%. Further improvements can be achieved though by optimizing the actual drawing sequences. – Bas Schouten

I spent Monday and Tuesday working with Bas’ tool trying to fix some of the invalidation bugs that we were seeing. After I had one of the patches ready for review, we found that the invalidation issues were the cause of another bug and was only reproducible if the user had enabled an off-by-default preference.  While my bug fix was void, the knowledge gained was very valuable. Tim Taubert was able to work around the root cause of the invalidation issue and fix the browser.newtab.preload implementation to remove the extra invalidations.

I’m really happy to see this tool though, as issues like these could never be discovered without it.

Benoit works from Toronto and is also on the Graphics team. Benoit picked up a side project to implement a native profiler in to Firefox. This profiler is used to find areas of jank within the browser. Getting a profile of the browser is only a click away when the browser becomes unresponsive. These profiles greatly help Firefox developers fix these responsiveness issues.

To use the Gecko Profiler you will need to run a Nightly build of the browser and install the Gecko Profiler add-on. The add-on installs itself in to the Add-On Bar at the bottom of the browser. Pressing Ctrl+Shift+O will show the current profile.

I spent the second part of the week working on fixing one of the issues that the profiler found. The code for highlighting the base domain in Firefox contained some inefficient regular expressions and  I was able to replace them with simple string manipulation. This improvement sped up the function by ~40%.

Overall I think the Snappy work week was really productive. It’s really nice to get people from various teams in the same room for a week since the barrier to communication is much lower. Weeks like these are even more valuable as a way to get to know your coworkers since IRC and Bugzilla aren’t perfect ways to express your thoughts.

Update (24 Sept): I included a clarification from Bas on the 95% redundancy remark.

Site-specific permissions for Firefox’ opt-in plugins

Today I landed an implementation of site-specific permissions for Firefox’ opt-in plugins. I previously wrote about Firefox 14’s non-default support for opt-in (also known as click-to-play) plugins last week.

That blog post garnered a lot of attention. Over 25 news sites covered the news, and the blog post was viewed close to 3,000 times.

Many people downloaded the Nightly version of Firefox to test out the feature, and a few people have told me how they are now using the feature full-time. Today’s addition of site-specific permissions makes using the feature much easier.

With site-specific permissions, users can whitelist sites that they visit often and trust. Sites that are whitelisted will activate plugins automatically upon load.

To add site-specific permissions, click on the plugin block in the location bar. The doorhanger that appears contains a dropdown with options to: Activate plugins; Always activate plugins for this site; Never activate plugins for this site; and Not Now.

To manage these permissions, users can click on the site-identity block next to the website address. From there, click on “More Information…“. The Page Info dialog will now appear. Clicking on the Permissions tab of the dialog will show any site-specific permissions that are stored for the current site, as well as the ability to change any of those permissions.

This feature will remain disabled by default in Firefox 14. David Keeler is also helping implement the feature, and has most recently been working on adding the ability to only enable plugins of a specific runtime (Flash, Java, Silverlight, etc). For more information on the status of the feature, see our feature page for Opt-in Activation of Plugins.

Opting-in to plugins in Firefox

Whether you hate them or love them, content accessed through plugins is still a sizable chunk of the web. So much so, that over 99% of internet users have Flash installed on their browser. However, plugins can also carry with them extra vulnerabilities and system slowdowns.

A couple days ago I landed an initial implementation of “click-to-play plugins” in desktop Firefox. To see and play with the feature, download a Nightly build of Firefox, go to about:config, and enable the plugins.click_to_play flag.

When plugins.click_to_play is enabled, plugins will require an extra click to activate and start “playing” content. This is an incremental step towards securing our users, reducing memory usage, and opening up the web.

I’m currently working on implementing the ability for plugin activation settings to be remembered on a per-site basis. I hope to get these changes landed within the next week before the deadline for Firefox 14.

If you are curious and want to learn more about our plans for opt-in activation of plugins, you can take a look at the feature page on our wiki.

Firefox Performance/Snappy work week recap

This past week I’ve been in Brussels, Belgium with about 15 people from Mozilla’s performance and front-end teams. This week we focused on what improvements we could make to the Mozilla platform and Firefox.

On Monday and Tuesday we were located at HSBXL, a hackerspace in central Brussels. While at HSBXL, people from the two teams did demos on tools that we can use to measure the performance of Firefox:

• Felipe (@felipc) demoed the Simple Profiler System that landed in Firefox 11.
• David Teller (@imyoric) demoed how to use xperf for tracking main-thread I/O.
• Dietrich (@dietrich) introduced the team to Peptest, an “automated testing framework designed to test whether or not the browser’s UI thread remains responsive while performing a variety of actions”.
• Taras (@tarasglek) demoed about:jank, an early-stage add-on that shows how often certain predetermined places within the codebase have been reached.
• I (@weinjared) demoed how to make bullet-time screen captures of Firefox and paint flashing.

Wednesday through Friday we went to another side of town to visit the BetaGroup coworking space. Our first topic upon arrival was a telemetry-athon that Dietrich setup to get together a list of telemetry probes that we could build into Firefox. Telemetry is another tool that we use to measure the responsiveness of various parts of Firefox.

Telemetry probes

Marco (@mak77) worked on telemetry probes for: idle maintenance time; frecency update time; and bookmarks toolbar load time.

Felipe and Marco started looking into switching-tabs telemetry, and have put together an experimental patch to check the results. They will need some deeper checks at the platform level to proceed with this work. Felipe also has been writing some telemetry stopwatch helper modules.

Dietrich spend some time implementing session restore telemetry, as well as making session restore periodic updates work asynchronously.

Neil worked on adding telemetry for measuring the time it takes for new windows to open.

Paolo worked on adding telemetry metrics for private browsing transitions. It looks like this work is stalled while we figure out the status of work being done by an academic group.

I landed telemetry probes that measure how long it takes for the site-identity popup and the Firefox menu to appear.

Thread contention

Marco figured out two possible causes for recent UI hangs due to thread contention. A fix, authored by Paolo Amadini, for one of the causes is on its way to landing and work on the other one is starting. Marco checked some queries possibly causing thread contention with Vlad Djeric.

DOM Storage

On the topic of DOM Storage, we had a great talk about reducing I/O and making it asynchronous. Tim (@ttaubert) is looking in to changing the way that we store the data so it will have faster read and write times.

Other topics

The photos in this blog post were taken by Dietrich Ayala and are licensed as creative-commons sharealike.

Paolo and Marco discussed converting the favicons API to use asynchronous methods.

A lot of work got done while we were in Brussels, and the team got to talk in person with each other which isn’t always so easy to do. I was very happy to get to meet Paolo for the first time, as he has been working on the new Download Manager for Firefox and a person I’ve been in contact with but never seen him before.