Electrolysis/Short-Term Goals: Difference between revisions

clear the page of old information
(clear the page of old information)
 
Line 1: Line 1:
= Current Goals =
= Current Goals =


== Deploy Dynamic Analysis to mozilla-central ==
The work on content processes has been suspended so that we can focus on more immediate responsiveness efforts. See [http://lawrencemandel.com/2011/11/15/update-on-multi-process-firefox-electrolysis-development/ lmandels' blog post] for details.
 
Followup to the initial dynamic analaysis goal: clean up the patch that is written, write some simple testcases to ensure correct behavior, and land the analysis to mozilla-central debug builds (off by default).
 
Owner: Drew Willcoxon
Goal date: 29-Sep
Status: Patches reviewed, revisions ongoing (data already being used by the frontend teams)
Bug: {{bug|666713}}
 
== Make basic Firefox navigation use the Message Manager ==
 
In order to make the dynamic analysis useful for estimating Firefox frontend work, we need basic page navigation to not produce any warnings. This means that current uses of web progress listeners in the Firefox frontend should be ported to the message manager.
 
It is ok for this goal to ifdef out certain features (such as aero tab previews) which are known not to work and are not essential to running mochitests.
 
A couple of key things in progress.
* Session store - Paul will take this when he gets back from vacation.
* Dynamic navigation - Felipe still working on this.
 
Owner: Felipe Gomes
Goal date: ?
Status: in progress
 
== Static Analysis of Chrome/Content Interaction ==
 
Parallel to the dynamic analysis, we need to be able to statically identify code patterns which may require rewriting (mainly in long-tail extensions). This will be an ongoing project, but we need to set intermediate goals (obvious patterns that we should start flagging). Refinement will depend on analysis gathered in the dynamic phase. {{bug|675014}}
 
Owner: Dave Herman
Status: Ongoing. .addEventListener analysis written. Need to add .contentWindow and .contentDocument patterns and add a framework for new patterns in the future. Need to classify scripts into content scripts and regular scripts for ongoing analysis work.
 
== Extension Usage Metrics ==
 
Identify which extensions must be compatible with content processes in order to reach 80% of Firefox users.
 
Owner: lmandel
Goal Date: 20-Oct
 
== Accessibility Tuning ==
 
Fix a couple bugs found during the initial a11y hookup and do QA to identify remaining problems.
See meta [http://bugzilla.mozilla.org/show_bug.cgi?id=646596 Bug 646596] for overall status.
 
2011-10-13
* Blocked by {{bug|693644}}
 
2011-10-06
* <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=673958 Bug 673958]</strike> landed for FF10.
* Working on <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=677883 Bug 677883]</strike> this week.
 
2011-09-29
* Team ready to sign off on goal after <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=673958 Bug 673958]</strike> and <strike>[https://bugzilla.mozilla.org/show_bug.cgi?id=677883 Bug 677883]</strike> are fixed. jmathies looking at the bugs this week.
* Linux contributor is MIA. Need to follow up on work in 4Q.
 
 
 
Owner: dbolter, jmathies
Goal Date: ? (investigation week of Sept. 26)
 
== Deploy a Responsiveness Metric ==
 
Deploy a responsiveness metric which measures the average and maximum time away from the event loop.
2011-11-25
* responsiveness metric deployed
 
2011-10-26
* test was deployed and backed out due to issue on OSX - fix in progress
 
2011-10-18
* test patch updated in <strike>{{bug|631571}}</strike>
* test patch being tested this week
* ready for deployment in 1-2 weeks
* will initially be rolled out on trunk, can enable on branches as well
* initial metric can be calculated as follows:
def responsiveness_Metric(val_list):
  s = sum([x*x / 1000000.0 for x in val_list])
  return str(round(s))
 
On track. Need to<br/>
1) enable tests on test machines - patch ready, jmaher will pick up final deployment<br/>
2) complete metrics work (metrics team)
 
 
Metrics visible on [http://graphs-new.mozilla.org/#displayrange=7&branch=firefox&platform=%5B%22windows7%22%2C%22windowsxp%22%2C%22macosx%22%2C%22linux%22%5D&test=%5B%22ts%22%2C%22tp%22%2C%22ss%22 graphs-new]
 
Owner: jmaher, tmielczarek
Goal Date: 28-Oct (for test automation)
 
== Implement Session Restore ==
 
Implement the "restore" half of session save/restore per the posted plan.
 
Owner: ? (was jez, internship finished)
Goal Date: TBD
 
== Analyze Jetpack SDK-based addons for low-level module usage ==
 
Addons written with the Jetpack SDK high-level APIs should automatically be compatible with content processes. Analyze existing SDK-based addons for usage of low-level APIs which may not be compatible with content processes and create a report for developers. NOTE: this should probably be combined with the static analysis of "old-style" addons above.
 
Owner: Brian Warner
Goal Date: 29-Sep
 
== Make the Jetpack SDK compatible with content processes ==
 
The Jetpack API should already be compatible, but the implementation will need to change. The Jetpack team is already working towards this goal for mobile.
 
Status tracked in the feature [https://wiki.mozilla.org/Features/Jetpack/Out-of-Process_Addons Jetpack Out-of-Processs Addons] and [http://etherpad.mozilla.org:9000/E88BefaXqC this etherpad].
 
Owner: ejpbruel (and myk and dcm)
Goal Date: TBD
 
== Remote IndexedDB for multiple content processes ==
 
The current implementation of IndexedDB needs to be reworked to work on multiple content processes. {{bug|666693}}
 
Owner: khuey
Goal Date: Postponed until Q22012
 
== Find an owner for remaining remote graphics work ==
 
Owner: jpr
Goal Date: 29-Sep
 
== Implement core handling of plugins on one platform ==
 
Multiple content processes that create instances of the same plugin (e.g. Flash) all need to talk to the same plugin subprocess.  This requires refactoring our plugin architecture into two parts: (i) a "plugin subprocess" abstraction, which will continue to be managed by the chrome process, and a (ii) "plugin instance creator" piece, which will create and manage plugin instances of a given plugin type, on behalf of possibly many clients (content processes).  Currently both are implemented by PPluginModule.  When content processes are disabled, the implementation will look almost exactly like the current one.  At the end of this milestone, the architectural foundations will be laid, and '''windowless''' plugins will work with multiple content process on at least one platform.
 
There are two potentially large compatibility implications
# With out-of-process content, the process of instantiating a plugin will change, and might require spinning the event loop to maintain a synchronous illusion.  If we do end up needing to spin the event loop, there are potential web compat issues.
# With out-of-process content, the chrome process will '''not''' be able to instantiate plugins.  This obviously won't affect the Firefox frontend, but it will affect extensions.  This isn't arbitrary or negotiable; it's just something that's not technically feasible to support without a heroic engineering effort (and since it's bad UX anyway, not at all worth that cost).  We need to start communicating this to extension developers ASAP.
 
This work will primarily happen in {{bug|641685}}.
 
Owner: cjones  Goal Date: Sept 26--Oct 3
Status: in progress
 
= Completed Goals =
 
== Dynamic Instrumentation for Chrome/Content Interaction ==
 
We want to identify:
 
* non message-manager scripts
* which touch a "content object"
* or implement nsIWebProgressListener
 
Definitions:
 
Non message-manager script is any chrome script that isn't run through nsIChromeFrameMessageManager.loadFrameScript.
 
Content objects are at least the following:
 
* Any DOM object (window, document, or node)
* Docshell or docshell derivative
* nsIWebProgress
* nsIDOMWindowUtils
 
Owner: Drew Willcoxon
Goal date: 30-June
Status: DONE (patch and initial analysis complete)
 
== Identify Work Items for Multiple Content Processes ==
 
We have identified multiple content processes as a requirement for desktop Firefox. Identify and find owners for the work required for multiple content processes.
 
Owner: Benjamin Smedberg
Goal Date: 23-June
Status: DONE (feature bugs filed... memory analysis will be later)
 
== Accessibility Engineering Plan ==
 
Identify whether the accessibility tree will need to be mirrored, or whether accessibility tools can work directly with trees in content processes.
 
Owner: David Bolter
Goal Date: 7-July
Status: DONE (posted to mozilla.dev.planning)
 
== Developer Tools Engineering Plan ==
 
Identify how existing in-product developer tools will be made compatible with content processes and what additional platform support is required. DOM Inspector will almost certainly require some additional platform support.
 
Owner: Rob Campbell
Goal Date: 7-July
Status: DONE (posted to mozilla.dev.planning)
 
== Get Firefox Starting Up ==
 
Get Firefox to start up and browse, so that the accessibility, devtools, and perhaps Jetpack SDK teams can work on dependencies.
 
Owner: Felipe Gomes
Goal date: 23-June (Wednesday)
Status: done
 
== Connect the chrome/content accessibility tree on Windows ==
 
Implement the basic a11y plan on Windows with a hidden HWND and a connected cross-process a11y tree.
 
Owner: Alexander Surkov
Goal date: 21-July
Status: done
 
 
== Write Session-Restore Plan ==
 
Publish a plan to revise session-restore for multiple content processes.
 
Owner: jez
Goal Date: 4-August
Status: done
Confirmed users, Bureaucrats and Sysops emeriti
1,217

edits