User:P.A./Address bar architecture improvements

Overview

The address bar in Firefox currently relies on Form Autocomplete infrastructure for a number of tasks:

• Handle keyboard input in the text field
• Open and display the panel with the suggestions for locations to visit
• Read the list of suggestions to display, through an autocomplete provider for the Places database
• Handle keyboard navigation in the panel
• Accept and execute the navigation or action associated with selecting an item from the panel

While some of these may be similar to what is required by Form Autocomplete (for example, waiting some time after a key press before triggering a search), many others differ substantially in how they should be implemented. This led to the proliferation of special cases in the Form Autocomplete infrastructure to accommodate the needs of the address bar, and made the code difficult to maintain.

In fact, the address bar is a central part of the user experience, and as such has developed special use cases to which many users are accustomed, such as certain keyboard sequences leading to certain sites, based on the ordering of location suggestions. Since these developed spontaneously, they are not always captured by existing user interface tests. Trying to work with the current code, and keep correct handling of the common cases at the same time, makes progress slower when adding new features.

One of the ways to address these issues is incremental refactoring. Another approach, explored here, is prototyping a new codebase.

Prototype

The prototype would be developed with the following characteristics in mind:

• Developed as a front-end Desktop-only browser component
• Only used by the address bar, which is then disconnected from Form Autocomplete
• Generates suggestions non-generically
  • Makes queries to Places and gets results directly
  • Does not try to reuse Unified Autocomplete, but copies part of its queries
• Uses JavaScript in all places where it is possible
• Uses new JavaScript language features
• Designed for asynchronous execution
• Has UI testing simulating mouse and keyboard input

In the process of doing this, we may understand where it makes sense to factor code in reusable modules and where it doesn't. For example, some of the work to handle keyboard navigation could be used to improve the search bar as well, but this will be clear only after the prototype is ready.

The initial cases the prototype would support are:

• Support direct navigation using the ENTER key or the GO button
• Type a full address (http://www.mozilla.org/) and navigate to it
• Type a shorter address (www.mozilla.org) and navigate to it
• With a page in history, for example https://www.mozilla.org/en-US/contribute/:
  • Type a part of the address (www.mozilla.org) and navigate to the page
  • Type a part of the title (at present "Volunteer") and navigate to the page
• Type part of the title of an open tab and switch to it
• Style a bookmarked page differently in the suggestions

Some explorations would be made possible:

• Richer styling of suggestions
• More complex keyboard interaction in the panel
  • For example, search suggestions in the first row

Non-goals for the prototype:

• Match current address bar behavior
• Create a viable product (however, since this is a technology/implementation prototype, it will start with product-quality code)

Possible next steps

The purpose of the prototype is to understand whether there may be a way forward for this architecture. If so, the following steps would consist in:

• Identify clearer boundaries for reuse of existing components in the new architecture
• Bring existing components and tests into the new architecture, to match known use cases
• Honor a chosen subset of the currently supported address bar behavior preferences
• Switch to the new architecture on Nightly and discover more use cases
  • The key difference with the current state would be that the changes to adapt to those use cases could be done much faster than now, and with fewer regressions
• Release the new architecture when it matches use cases satisfactorily
  • Matching every single special case would be a non-goal