Firefox/Features/50ms ASSERT

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Primary UI Responsiveness - 50ms goal
Stage Complete
Status `
Release target `
Health OK
Status note Core instrumentation landed, resulting in various tools built on top of it. Current work utilizing these tools is the Snappy project. SDR: N SIR: N


Product manager Asa Dotzler
Directly Responsible Individual Dietrich Ayala
Lead engineer `
Security lead Curtis Koenig
Privacy lead `
Localization lead `
Accessibility lead `
QA lead AndreiD
UX lead `
Product marketing lead `
Operations lead `
Additional members ted (infrastructure lead)

Open issues/risks


Stage 1: Definition

1. Feature overview

Any time the user interface takes more than 50ms to respond to an action, the application will appear sluggish to the user. To determine how often this happens, and what parts of our code are frequent offenders, we should add the ability to detect when the main-thread event loop is delayed by more than 50ms and log it as an ASSERT.

However, just an ASSERT does not tell developers *what caused* the delay. In order to be useful, we must provide the ability for developers to easily get information about what code is slow.

There are generally two scenarios in which the browser UI is non-responsive.

  1. When a direct action by the user causes the app to be non-responsive. For example, a menu option that executes an action synchronously, and takes >50ms to return.
  2. When a background action blocks the event loop for >50ms, causing the whole app to be non-responsive.

The goal of this project is to get developer visibility into both scenarios with easy-to-use tools.

This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)

2. Users & use cases

  • provide insight to developers into what is causing the Firefox user interface to feel slow or unresponsive to users
  • identify high impact areas for UI responsiveness work

3. Dependencies


4. Requirements

  • Does not affect performance in production or beta builds
  • Can be logged to screen or file
  • Logging has been added to all primary user interface events


  • provide information to end-users about what is causing Firefox to feel slow or unresponsive
  • provide UI profiling
  • integration of responsiveness testing into Talos

Stage 2: Design

5. Functional specification


6. User experience design

--Alex 20:16, 31 May 2011 (PDT): Here's a possible UI for visualizing responsiveness. Note that the 50ms ASSERT is for discrete actions, anything that is continuous would need to log when the responsiveness was higher than 16.6ms during the action. In the visualization these appear as lines instead of dots (scrolling, moving the window, etc.)

Stage 3: Planning

7. Implementation plan


8. Reviews

Security review

  • No sec rev needed

Privacy review


Localization review




Quality Assurance review

  • No test plan needed

Operations review


Stage 4: Development

9. Implementation

Next Steps

  • Analyze logs from JS function calls and event loop instrumentation to determine if the correlations are useful or not (see bug 653701)
  • If useful, get bug 580055 landed asap, so we don't have to keep unrotting it
  • Correlate platform code unresponsiveness with event loop log (telemetry)
  • Hooks to trigger profiling tools on event loop unresponsiveness (eg: Shark, CHUD, Instrument, Systemtap, xperf)
  • Instrument front-end UI actions (telemetry output?)
  • Write HOWTO for easy correlation of code/actions to unresponsiveness
  • Identify top 10 slowest-responding primary UI actions
  • Identify top 10 platform code points causing event loop delays
  • Fix the above


  • Complete project definition (ETA: 2011/04/01, Beltzner, Complete)
  • Work with UX to identify 15 primary UI events (ETA: 2011/04/01, google doc, Dietrich, Complete)
  • Implement core instrumentation of event loop (bug 601268, Ted, Complete)

Related Bugs & Dependencies

  • bug 651580 - tracking bug
  • dependency graph
  • Related Bugs
    • bug 601268 - adds "canary in a coal mine" instrumentation to nsThread.cpp (MOZ_CANARY)
    • bug 606574 - add event loop responsiveness instrumentation (MOZ_INSTRUMENT_EVENT_LOOP_OUTPUT)
    • bug 653701 - Figure out a way to correlate JavaScript execution with event loop non-responsiveness
    • bug 653703 - Correlate C++ profiling with event loop non-responsiveness
    • bug 580055 - log all JS function entry/exits
    • bug 667036 - Add support for using DTPerformanceSession from javascript

Related Projects

  • About:Response - add-on that tracks response time of browser features

Related Documents

Stage 5: Release

10. Landing criteria


Feature details

Priority P1
Rank 3
Theme / Goal `
Roadmap User Experience
Secondary roadmap `
Feature list Desktop
Project `
Engineering team Desktop front-end

Team status notes

  status notes
Products ` `
Engineering ` `
Security pass Determined no security review needed
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance OK with landing in Firefox 6 Not a user facing feature. The dev team is taking the decision for the sign-off since it is a specific feature for product development
User experience ` `
Product marketing ` `
Operations ` `

Other Documentation