Firefox Core Engineering

From MozillaWiki
Jump to: navigation, search
Stop (medium size).png
The Firefox Core Engineering (FCE) team ran from March 2016 through January 2018. All work on that team has been dispersed to other teams.

This page should be considered legacy.

For more information on previously-FCE activities, go by individuals listed in Historical knowledge areas. (If you're in a pinch, ask ddurst.)


The purpose of this team is to address needs that fall between Toolkit and Platform, with an emphasis (currently) on improving stability, quality, and performance – supported by empirical data. As such, we overlap a bit with everyone from Gecko, Desktop, Data, and more.

This team grew out of, in part, the Performance Engineering team, and owns some of that team's infrastructure – some performance-related dashboards on, crash analysis, hang visualization, etc. It also includes the installer & updater applications.


  • Neil Deakin (:enn)
  • Adam Gashlin (:agashlin)
  • Felipe Gomes (:felipe)
  • Matt Howell (:mhowell)
  • Chris HC (:chutten) -- honorary
  • Kirk Steuber (:bytesized)
  • Robert Strong (:rstrong)
  • Gabriele Svelto (:gsvelto)
  • Doug Thayer (:dthayer)
  • David Durst (:ddurst)


  1. Enabling stability
    In general, things we do should be tied to enabling stability – so, making it measurable and/or addressing issues.
  2. Supporting performance improvements
    Improving performance is certainly everyone's job—not just our team—but we hold the keys for some distinct historical pieces of the analysis that allow people to understand what needs to be improved. This is primarily, but not limited to, telemetry and data analysis.
  3. Improving the user/contributor experience
    This one is the weirdest: it covers things that we can do to further the web, and improve the experience for our users – both end users and code contributors (some examples: Flash blocking, XUL performance analysis). This category is the most open-ended for future expansion.


You can typically find us in:


  • #fce (primary)
  • #developers
  • #e10s
  • #fx-team
  • #perf
  • #releng
  • #telemetry
  • #uptime

Mailing lists

  • dev-platform
  • fhr-dev
  • firefox-dev

Process and Queuing

There is currently no regimented process for regular triage of candidate work. Needs usually filter down through performance analysis and experimentation.

All actively tracked work is marked with the whiteboard "[fce-active-legacy]" (for now). Or look at the #Active Bug List on this page.

Major initiatives are listed on this page.

Owned Infrastructure (needs updating per 1298080) Dashboards

  • Update Orphaning: functional

This is the symbolication server (aka "Snappy Symbolication Server") used by platform developers and performance dashboards. It is not used for the analogous process on Socorro. This is currently slated to be replaced by the owner of symbols, peterbe. See Tecken.

Historical knowledge areas

  • back-end of the user interface/XUL, et al (enn)
  • e10s system add-ons & system add-ons for feature rollout (felipe)
  • e10s data analysis (chutten)
  • install and update (rstrong, mhowell)
  • telemetry, histograms, pings, and data reporting (chutten)
  • stack-walking, breakpad, and crash pings (gsvelto, ccorcoran)
  • flash plugin-related (bytesized, felipe, dthayer)
  • policy engine and MVP (felipe, bytesized)
  • migration performance, BHR dashboard (dthayer)


Get More Data Faster

We need to reduce known blind spots and barriers to getting data AND commit to non-ADI based metrics. For this, our goals are to:

  • process stack data in crash pings into a queryable result (1310695)

See the legacy roadmap here.

Set Flash to CTA by default

This includes:

  • prefer fallback content to Flash (1277346)

See the details here.

XBL/XUL replacement

TBD with and after Browser Architecture's recommendations.

Policy Engine

When implemented, this should provide an API for pre-defined policies to support enterprise management of Firefox deployments.

Migration performance optimization

With bug 1332225, investigate and optimize the migration process for new users.

App Updater and Installers

Update Orphan remediation

Remediation efforts have been tested for both system add-on capable and non (44.x and 43.0.1, respectively). Efforts are identified by ongoing analysis, including the update orphaning dashboard. This has yielded such things as:

  • continue the download instead of starting over after other networking errors occur (1309124, 1348087)
  • create an Update Agent, responsible for running independently, daily, and downloading an update if found (1343669)
  • create a dashboard for non-orphan telemetry analysis


  • rename installed links to "Firefox" instead of "Mozilla Firefox" (1413295)
  • stub installer metrics (995794)
  • investigate MSI-based (read: non-NSIS) installer

Current projects

2018 Q1 goals

  • APP UPDATE (see legacy roadmap):
    • Allow update download to continue in the background (beyond Firefox session)
  • INSTALLER (see legacy roadmap):
    • Outline plan for MSI-based installer
    • Support onboarding
  • CRASH MACHINERY (see legacy roadmap):
    • (Implement crash ping signatures) -- relies on Data Pipeline
    • (Start querying stacks received from crash pings for stability monitoring) -- relies on PI
    • Assist with measuring (and identifying) jank and hang via BHR
    • Assist with performance improvements for migration
    • Prototype policy engine and policies MVP (for 59 beta tests, release in 60)
  • XUL:
    • Assist Browser Architecture team's flexbox recommendation effort

Potential future projects

This list should be considered a work in progress. Decisions will be reflected for a particular quarter.

  • cmore is pitching that Firefox optimizes the user paths that support retention -- which could also include fixing paths where retention drops. This work probably involves a system add-on that initiates event-based recordation, as well as the analysis and remediation of the root cause (this is pending dcamp approval).
  • DLL injection (see needs investigation/implementation of a dynamically updateable DLL blocklist (possibly using Kinto?).
  • Mossop (& browser arch) has begun the de-XBL. Overall browser architecture (& UI architecture) could be game in the near future.

(partial) Active Bug List

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);