Skip to content

Instantly share code, notes, and snippets.

@rhelmer
Last active March 18, 2017 21:40
Show Gist options
  • Save rhelmer/35e9de769784f6b40178d867720f916d to your computer and use it in GitHub Desktop.
Save rhelmer/35e9de769784f6b40178d867720f916d to your computer and use it in GitHub Desktop.

[DRAFT] Go Faster Status

Restartless features

Firefox updates typically require an application restart. Users may choose to delay restart for an indeterminate length of time [1]. This not only delays the application of new user-visible Firefox features, but also important bug and security fixes.

Restartless features provide a method to serve chrome-privileged content to Firefox users, without requiring a full restart. The current mechanism used to provide this method are system add-ons [2], developed as part of the Go Faster project [3].

Examples of current and in-development future restartless features which are directly visible to the user are:

  • Activity Stream
  • Pocket
  • Form Autofill
  • Webcompat Reporter
  • Page Shot

Background activities have been implemented as restartless features as well, such as:

  • update and deployment diagnostics
  • multiprocess (e10s) staged roll-out
  • user studies (shield)

Features may be developed as Firefox extensions which ship with the application and are available at startup on first run. Updates can be made available outside of the usual 6-week Firefox release cycle by using the system add-on update mechanism [4].

Privileged add-ons, such as those used by Test Pilot, can choose to override restartless features. Users may opt in to this installing a privileged add-on, and revert to the latest official Firefox version of a feature by removing the add-on.

Hotfixes

It is not always appropriate to serve a bug or security fix directly with affected feature - sometimes a mitigation or workaround should be launched immediately after discovery, while a complete fix is prepared. This complete fix may require application restart or simply be relatively complex and require more development and testing time.

To provide for this, hotfixes may be served as system add-on updates [4].

Some recent uses for this mechanism have been:

  • mitigate damage from malware targeting Firefox
  • stop users from crashing due to factors in the local environment (eg Websense install)
  • enable or disable settings causing web compat or security issues in the wild
  • test how well new features such as TLS 1.3 work for users in the release population before shipping

Next

The process for developing and serving updates has room for improvement:

  • Updates are checked shortly after application startup, and only once every 24 hours after that [5].

These could potentially be checked much more rapidly, possibly every few minutes [6].

  • Firefox extensions can run any code with full chrome privleges with no restrictions. For many hotfixes, writing a complete Firefox extension is necessary, but there is a subset that could be satisfied by modifying prefs remotely.

[TODO TALK TO FELIPE ABOUT PLANS FOR THIS]

Further, using simple feature flags for new Firefox features makes this relatively safe.

This requires that Firefox developers are using flags and testing both the default and non-default case. In case these condition are not satisfied, a complete Firefox extension can be used.

  • The signing and staging process for system add-ons requires manual coordination, tracked in Bugzilla.

Work on automating this process is underway [7]

  • Tracking uptake of updates served requires custom Telemetry dashboards which must be updated manually

[TODO FIND EXAMPLES OF PROJECTS DOING THIS BETTER AND/OR EXPECTED TELEMETRY IMPROVEMENTS]

  • Uplifting features into the appropriate hg.mozilla.org repositories is time consuming
    • For instance, a feature that ships to release users should be landed in the release and beta repositories as for nightly, so the feature is available built-in to the next version of Firefox.
  • Coordinating landings in hg.mozilla.org (hg.m.o) from projects that are primarily hosted elsewhere (such as Activity Stream and Page Shot) is difficult.
    • For Firefox test coverage to be complete, the latest version of built-in features should in hg.m.o as soon it ships to users.
    • It is very common for the result of refactoring and bug fixes to be made directly to vendored libraries in hg.m.o, being able to "upstream" these easily is important.

There is work in progress on bi-directional merging between hg.m.o and Github for the Quantum project [8], which depends on Servo and related dependencies, which are primarily developed on Github but need to be vendored into hg.m.o in order to ship with Firefox.

Footnotes

  1. [TODO INSERT TELEMETRY ON AVG SESSION TIME]
  2. http://foxdocs.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html
  3. [TODO INSERT GO FASTER PROJECT INFO]
  4. http://foxdocs.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html#system-add-on-updates
  5. http://foxdocs.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html#firefox-system-add-on-update-protocol
  6. [TODO INSERT LINK ABOUT FASTER UPDATES]
  7. [TODO INSERT LINK ABOUT SIGNING AUTOMATION]
  8. [TODO INSERT LINK ABOUT BIDI MERGING]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment