Mozilla 2: Difference between revisions

Jump to navigation Jump to search

Mozilla 2 (view source)

Revision as of 10:07, 15 February 2010

18 bytes added ,  15 February 2010
m
No spam
No edit summary
m (No spam)
Line 1: Line 1:
(See [[Mozilla 2/Old Moz2|the 2004-era Mozilla 2 pages]] for older ideas.)  
(See [[Mozilla_2/Old_Moz2|the 2004-era Mozilla 2 pages]] for older ideas.)


== Project Status ==
== Project Status ==


See the [[Platform#Meeting_Notes|latest status meeting notes]].  
See the [[Platform#Meeting_Notes|latest status meeting notes]].


=== Work List ===
=== Work List ===


A detailed list of items that we are working on can be found here:  
A detailed list of items that we are working on can be found here:


[[Mozilla 2/Work List|Mozilla 2 Work List]]  
[[Mozilla 2/Work List|Mozilla 2 Work List]]


=== Ends ===
=== Ends ===


Current thinking on goals, initially pitched in [[User:Brendan|Brendan]]'s [http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html Mozilla 2 blog item], consists of these major bullet items:  
Current thinking on goals, initially pitched in [[User:Brendan | Brendan]]'s [http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html Mozilla 2 blog item], consists of these major bullet items:


*Clean up our APIs to be fewer, better, and "on the outside" of Gecko, with symbol visibility strictly limited to public APIs.  
* Clean up our APIs to be fewer, better, and "on the outside" of Gecko, with symbol visibility strictly limited to public APIs.
*Based on these APIs and supported embedding scenarios, support intentional Gecko embedding in a first-class way.  
* Based on these APIs and supported embedding scenarios, support intentional Gecko embedding in a first-class way.
*Simplify the Mozilla codebase to make it smaller, faster, and easier to approach and maintain.  
* Simplify the Mozilla codebase to make it smaller, faster, and easier to approach and maintain.
*Take advantage of standard C++ features and fast paths instead of XPCOM and ad hoc code.  
* Take advantage of standard C++ features and fast paths instead of XPCOM and ad hoc code.
*Implement [http://www.ecmascript.org/ JS2] on top of [[Tamarin]] via [[JavaScript:ActionMonkey|ActionMonkey]].  
* Implement [http://www.ecmascript.org/ JS2] on top of [[Tamarin]] via [[JavaScript:ActionMonkey|ActionMonkey]].
*Optimization including JIT compilation for JS2 with very fast DOM access and low memory costs.  
* Optimization including JIT compilation for JS2 with very fast DOM access and low memory costs.
*Tool-time and runtime enforcement of important safety properties including memory safety and confidentiality properties for both XUL and the Web.  
* Tool-time and runtime enforcement of important safety properties including memory safety and confidentiality properties for both XUL and the Web.
*Rich graphics support including accelerated SVG/Canvas and Video Support
* Rich graphics support including accelerated SVG/Canvas and Video Support


=== Anti-Goals ===
=== Anti-Goals ===
What these mean in detail is mostly "to be decided", but we should try to say what we don't mean:


What these mean in detail is mostly "to be decided", but we should try to say what we don't mean:
* We won't rewrite the Mozilla codebase by hand.
* We won't gratuitously break API compatibility ("some of our APIs are fine, thank you").
* We won't drop XPCOM completely; we may even have configurable Mozilla 1 XPCOM compatibility.
* We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does).


*We won't rewrite the Mozilla codebase by hand.
The goals boil down to competing more effectively with ourselves, with [http://webkit.org/ Webkit], and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparable), and C++ embeddable HTML rendering engine platforms. We should aspire to beat the competition on major time, space, and ease-of-use axes, not just show or place.
*We won't gratuitously break API compatibility ("some of our APIs are fine, thank you").  
*We won't drop XPCOM completely; we may even have configurable Mozilla 1 XPCOM compatibility.
*We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does).


The goals boil down to competing more effectively with ourselves, with [http://webkit.org/ Webkit], and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparable), and C++ embeddable HTML rendering engine platforms. We should aspire to beat the competition on major time, space, and ease-of-use axes, not just show or place.
=== Ongoing Work ===


=== Ongoing Work  ===
* [[JavaScript:ActionMonkey]]: Rewriting spidermonkey to use actionmonkey. This is also the man hg branch that Moz2 work is being done in
* [[XPCOMGC]]: Switch from reference counting to a GC
* [[Mozilla2/November-Agenda]]
* [[Gfx glue layer removal]]


*[[JavaScript:ActionMonkey]]: Rewriting spidermonkey to use actionmonkey. This is also the man hg branch that Moz2 work is being done in
=== Tools ===
*[[XPCOMGC]]: Switch from reference counting to a GC
*[[Mozilla2/November-Agenda]]
*[[Gfx glue layer removal]]


=== Tools ===
The goals are ambitious, and unrealistic without new tools and approaches to the code. Here are some of the major levers we use to move mountains.
* Moz2 uses [http://www.selenic.com/mercurial/wiki/ Mercurial] for version control
* [[Pork]] tool suite contains the source rewriting tools.


The goals are ambitious, and unrealistic without new tools and approaches to the code. Here are some of the major levers we use to move mountains.
=== More Info ===


*Moz2 uses [http://www.selenic.com/mercurial/wiki/ Mercurial] for version control
The info below has not been significantly updated since December 2006
*[[Pork]] tool suite contains the source rewriting tools.


=== More Info  ===
==== Tasklist ====


The info below has not been significantly updated since December 2006
* Import final dirlist into Hg (Benjamin/Brendan)


==== Tasklist  ====
* Begin refactoring work/deCOMtamination/API work
** Get tools good enough for broad use (Taras)
** Develop hitlist of areas to refactor (Taras/Brendan)
** Plan for refactoring DOM APIs (JST)


*Import final dirlist into Hg (Benjamin/Brendan)
* Complete ES4 spec and ref impl (Brendan/Graydon)


*Begin refactoring work/deCOMtamination/API work
* Begin Tamarin/SM integration
**Get tools good enough for broad use (Taras)  
** Extract GC from Tamarin - remove all flash deps (TBH)
**Develop hitlist of areas to refactor (Taras/Brendan)  
** Ensure GC/Taramin compiles/runs on all platforms (TBH)
**Plan for refactoring DOM APIs (JST)
** [[XPCOMGC]] object model


*Complete ES4 spec and ref impl (Brendan/Graydon)
* Rich Graphics Plan
** Video Prototypes (Chris D)
** SVG/Canvas Plan (Vlad)
** Accelerated Graphics Plan (Vlad)
** OpenText Improvements Plan (Pav)


*Begin Tamarin/SM integration
* Security Plan (Window)
**Extract GC from Tamarin - remove all flash deps (TBH)  
* Layout Plan (Roc/DBaron)
**Ensure GC/Taramin compiles/runs on all platforms (TBH)  
**[[XPCOMGC]] object model


*Rich Graphics Plan
==== Old Timeline ====
**Video Prototypes (Chris D)
**SVG/Canvas Plan (Vlad)
**Accelerated Graphics Plan (Vlad)
**OpenText Improvements Plan (Pav)


*Security Plan (Window)
* Q107 - Kickoff of project
*Layout Plan (Roc/DBaron)
** VCS up and ready for checkins
** Major areas of focus identified
** Owners for each area identified


==== Old Timeline  ====
* Q207
** ES4 Spec and Ref Impl Draft
** Plans flushed out for each major task area
** Refactoring tools usable by wider audience
** Prototype VIDEO Tag


*Q107 - Kickoff of project
* Q307
**VCS up and ready for checkins
** ES4 Spec and Ref Impl Complete
**Major areas of focus identified
** Refactoring work begun
**Owners for each area identified
*** Elimination of raw pointers
*** Shift to STD C++


*Q207
* Q407
**ES4 Spec and Ref Impl Draft
** Tamarin GC Building on all major platforms
**Plans flushed out for each major task area  
** First prototype of Tamarin
**Refactoring tools usable by wider audience
** Design/Prototypes done for each major area
**Prototype VIDEO Tag


*Q307
* Q108
**ES4 Spec and Ref Impl Complete
** First Alpha of Moz2/Gecko2/Fx4 released
**Refactoring work begun
***Elimination of raw pointers
***Shift to STD C++


*Q407
* Q208
**Tamarin GC Building on all major platforms
** Fx4 Alphas
**First prototype of Tamarin
** All Major design work done
**Design/Prototypes done for each major area


*Q108
* Q308
**First Alpha of Moz2/Gecko2/Fx4 released
** First Fx4/Moz2 Beta


*Q208
* Q408
**Fx4 Alphas
** Betas
**All Major design work done


*Q308
* Q109
**First Fx4/Moz2 Beta
** Moz2/Fx4 Ship


*Q408
==== A Better VCS (Brendan/Preed) ====
**Betas


*Q109
See [[VersionControlSummit2006|the great Version Control System shoot-out]]. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least
**Moz2/Fx4 Ship


==== A Better VCS (Brendan/Preed) ====
* better, cheaper branching
* better merge algorithms for updating and landing branches
* decentralized operation (no master repository with slave workareas)
* good merge-from-CVS capability to track the Mozilla 1.9 trunk where possible
* great performance on Windows (this rules out cygwin-ported Linux VCSes)


See [[VersionControlSummit2006|the great Version Control System shoot-out]]. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least
See [http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html preed's Mortal Kombat] salute and look for news on his blog.


*better, cheaper branching  
An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful.
*better merge algorithms for updating and landing branches  
*decentralized operation (no master repository with slave workareas)  
*good merge-from-CVS capability to track the Mozilla 1.9 trunk where possible
*great performance on Windows (this rules out cygwin-ported Linux VCSes)


See [http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html preed's Mortal Kombat] salute and look for news on his blog.
==== ES4 ====


An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful.
* Ref implementation complete June 07
* Merge Tamarin in existing JS APIs
* Tamarin Performance Improvements (see above)
* JS Trust labels


==== ES4 ====
By combining APIs, code, and ideas from [http://lxr.mozilla.org/mozilla/source/js/src SpiderMonkey] and [http://lxr.mozilla.org/mozilla/source/js/tamarin Tamarin], we will build a [http://developer.mozilla.org/es4 JS2] virtual machine as part of Mozilla 2. The Tamarin code contribution is a big boost to this effort, and we intend to extend it, not copy code from it. But we need more than today's Tamarin in order to avoid certain pitfalls.  We will probably need all of these:


*Ref implementation complete June 07
* Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types).
*Merge Tamarin in existing JS APIs
* Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit).
*Tamarin Performance Improvements (see above)  
* Fresh thinking and hacking for VM-based security, learning from [[Security:Bibliography|recent security research]].
*JS Trust labels


By combining APIs, code, and ideas from [http://lxr.mozilla.org/mozilla/source/js/src SpiderMonkey] and [http://lxr.mozilla.org/mozilla/source/js/tamarin Tamarin], we will build a [http://developer.mozilla.org/es4 JS2] virtual machine as part of Mozilla 2. The Tamarin code contribution is a big boost to this effort, and we intend to extend it, not copy code from it. But we need more than today's Tamarin in order to avoid certain pitfalls. We will probably need all of these:  
We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider:


*Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types).
* Native compiler front end.
*Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit).
*Fresh thinking and hacking for VM-based security, learning from [[Security:Bibliography|recent security research]].


We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider:
While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for <code>eval</code> requirements (which will be novel to Flash in a future release).


*Native compiler front end.
Current DOM security checks use the [[Security:Scattered Security Checks]] model. For Mozilla 2, in order to JIT DOM calls efficiently, we need either [[Security:Security Checks In Glue]] or [[Security:Wrapper-based Checks]]. To support "mashups in the browser" and [http://www.w3.org/TR/XBL XBL2], we may need to support data-tainting with static flow analysis as well as dynamic taint propagation.


While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for <code>eval</code> requirements (which will be novel to Flash in a future release).
==== Semi-automated refactoring work/Oink ====


Current DOM security checks use the [[Security:Scattered Security Checks]] model. For Mozilla 2, in order to JIT DOM calls efficiently, we need either [[Security:Security Checks In Glue]] or [[Security:Wrapper-based Checks]]. To support "mashups in the browser" and [http://www.w3.org/TR/XBL XBL2], we may need to support data-tainting with static flow analysis as well as dynamic taint propagation.
[[Static Analysis]] via [[FirefoxSummit/2006/ProposedSessions/Oink|Oink]] will play an important role, we think, in partially or fully automating


==== Semi-automated refactoring work/Oink  ====
* deCOMtamination, including getting XPCOM completely out of the middle of Gecko
* static data-tainting checks to uphold confidentiality properties
* conversion to [[Exceptions|exception-safe code]], and holding the line on exception safety
* conversion to C++ exceptions, possibly including a new XPCOM C++ binding
* identification of C++ ripe for conversion to JS2.
* conversion from ad-hoc or Mozilla-private APIs to standard C++ APIs
* simple metrics of code complexity, to be regularly compared to other open source projects


[[Static Analysis]] via [[FirefoxSummit/2006/ProposedSessions/Oink|Oink]] will play an important role, we think, in partially or fully automating
Other good ideas for Oink-based tools should be noted on [[Static Analysis]].  The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at [http://weblogs.mozillazine.org/roadmap/archives/2006/11/oinkbased_patch_generation.html another this blog post].


*deCOMtamination, including getting XPCOM completely out of the middle of Gecko
==== Embedding API Design ====
*static data-tainting checks to uphold confidentiality properties
*conversion to [[Exceptions|exception-safe code]], and holding the line on exception safety
*conversion to C++ exceptions, possibly including a new XPCOM C++ binding
*identification of C++ ripe for conversion to JS2.
*conversion from ad-hoc or Mozilla-private APIs to standard C++ APIs
*simple metrics of code complexity, to be regularly compared to other open source projects


Other good ideas for Oink-based tools should be noted on [[Static Analysis]]. The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at [http://www.top-term-paper-sites.com term papers] or [http://www.omnibet.ro pariuri sportive]
* [[Mozilla 2/XPCOM and Binary Embedding]]
* [[Mozilla 2:Embedding APIs]]
* [[Mozilla 2:Obsolete APIs]]


==== Embedding API Design  ====
==== Rendering Performance ====


*[[Mozilla 2/XPCOM and Binary Embedding]]
==== Graphics/Advanced Rendering ====
*[[Mozilla 2:Embedding APIs]]
*[[Mozilla 2:Obsolete APIs]]


==== Rendering Performance  ====
* Get rid of remnants of old gfx
** convert all paint methods to take gfxContext instead of nsIRenderingContext
** optimize API usage, e.g. take advantage of new clipping/transform capabilities
* Add optional acceleration using OpenGL (or Direct3D)
** Involves work to make widget layer 3D-aware
* Add video capabilities to platform, combined with hw accel and complex transform capability
* Make 3D a first-class citizen of platform
** any 2D element should render correctly under an arbitrary 2D transform
* Tighter integration between image decoding and rendering
** decode-on-render
** SVG as image


==== Graphics/Advanced Rendering  ====
==== Security ====


*Get rid of remnants of old gfx
[[Category:Mozilla 2]]
**convert all paint methods to take gfxContext instead of nsIRenderingContext
**optimize API usage, e.g. take advantage of new clipping/transform capabilities
*Add optional acceleration using OpenGL (or Direct3D)
**Involves work to make widget layer 3D-aware
*Add video capabilities to platform, combined with hw accel and complex transform capability
*Make 3D a first-class citizen of platform
**any 2D element should render correctly under an arbitrary 2D transform
*Tighter integration between image decoding and rendering
**decode-on-render
**SVG as image
 
==== Security  ====


Security Ideas and Wish List for Post Gecko 1.9  
Security Ideas and Wish List for Post Gecko 1.9  


*attack surface reduction  
* attack surface reduction
*content restrictions, &lt;noscript&gt;, jail  
* content restrictions, <noscript>, jail
*next level private browsing  
* next level private browsing
*low privilege/protected mode, cross platform  
* low privilege/protected mode, cross platform
*xbl2  
* xbl2
*security review for every feature lightweight process to make it manageable  
* security review for every feature lightweight process to make it manageable
*offline stuff  
* offline stuff
*profile encryption  
* profile encryption
*identity management  
* identity management
*platform native keychain  
* platform native keychain
*all critical – moderate resolved through every major release
* all critical – moderate resolved through every major release
 
*documenting and enforcing invariants
**what is allows to happen when
**assert if you do that
*clean up assertions
**ones remaining really mean something
*regression test suite for security, pages to assert, measure leaks
*better compartmentalization of javascript between chrome and content
*addons/plugins
*out of process plugins;&nbsp;


[[Category:Mozilla_2]]
* documenting and enforcing invariants
** what is allows to happen when
** assert if you do that
* clean up assertions
** ones remaining really mean something
* regression test suite for security, pages to assert, measure leaks
* better compartmentalization of javascript between chrome and content
* addons/plugins
* out of process plugins
Tro
350

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/202282"

Navigation menu