From MozillaWiki
Jump to: navigation, search


1) Review and update goals

2) Confirm technical constraints, state and next steps


  • based on https://wiki.mozilla.org/Electrolysis/Firefox#Goals
  • these are first step goals
  • Better overall application UI responsiveness
    • yes, this is the overriding goal
    • this is the win
  • Improved performance, especially on multi-core machines.
    • 4th on list
  • Better memory core stats
    • need to be explicit - being able to exit content renderer - this is the real world of this goal
    • ben: requires multiple content processes
    • brend: this is a competitive must have (chrome, ie, safari)
  • Crash resilience A web content crash doesn't take down the entire browser.
    • "crash protection" is the re-phrasing
  • Preparation for sandboxing. Web content can be sandboxed more cleanly.
    • needs to be "crisped up"
    • architecture must allow for this
  • add-on compatability is a goal during implementation
    • CPOWs flexibility is a win for some number of add ons

Backend Electrolysis Pieces

  • not blocked by front end
  • long poles (benjamin)
    • accessibility
    • developer tools
    • probably needs front end to stand up to really start
    • gfx, some work to do, well underway
    • content, js no real worries

Front End

  • instrumenting number of crossover points for front end
    • needs measurement
    • if we need to lower the number of messages overall
      • different archictecture needed
    • docshell failures
      • require message manager even with CPOWs


  • The current technical state is that CPOWs will help: https://spreadsheets.google.com/spreadsheet/ccc?key=0Ag3-54eJ7D8OdDZ1U09kVEl1UnZ4QU1wVU9yS2dBcGc&hl=en_US
  • of top 26
    • 5 may work with CPOWs
    • 7-8 don't touch content
  • install an add on that is e10s incompatible, single process mode
    • jay: are we taking on a burden supporting this?
      • yes (blizzard, bsmedberg)
  • brendan: be less reactive about extension compatability
  • jay: js ctypes help
    • brendan why is this the case?
    • not a replacement for xpconnect
    • johnath: ctypes can help access 3rd party dll's that don't need to call back in
  • 85% of users have installed an add on from AMO
    • much higher than previously though
    • brendan: what API's are being used?
    • ben: are hard to measure - event listeners can access docshell
    • brendan: should measure - up our game and not do this by hand
    • bz, dolske could give input
    • andreas make proposal
      • work with johnath's team
  • decision: what kind of porting/help do we offer
    • will be driven by Andreas' data
    • measurement is key before CPOWs/front end re-write procedure

Response Time

  • Bob's team on this
  • need to know what to measure
  • response delay with main event loop
    • debug assert for > 50 MS assert
    • 651580

Project Management

    • Sheila/Benjamin/Blizzard/JP will collaborate for now, sync in ~1 week
    • Blizzard has action items

Public info

  • blogs
    • Goals (Blizzard)
    • CPOWs research (Johnath)
    • Response time tools (Ted will blog)

Next actions

  • Build static analysis tools (agal & damon)
  • Build dynamic instrumentation tools (bz, johnath, felipe, dietrich)
  • Continue building out front end lab rat (felipe)
  • Data for add-ons usage
  • Responsiveness tools bring-up (bob)
  • Flip memory and crash goals in the wiki
  • Expand memory description