Mozilla 2

(See the 2004-era Mozilla 2 pages for older ideas.)

Ends

Current thinking on goals, initially pitched in Brendan's 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.
• 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.
• Take advantage of standard C++ features and fast paths instead of XPCOM and ad hoc code.
• Develop JS2 with Adobe folks on top of Tamarin.
• 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.

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).

The goals boil down to competing more effectively with ourselves, with Webkit, and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparables), 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.

Means

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

Tasklist

• Import final dirlist into Hg (Q107)
  • Benjamin/Brendan
• Begin refactoring work/DeCOM/API work (Q107)
  • Get tools good enough for broad use (Taras)
  • Develop hitlist of areas to refactor (Taras/Brendan)
  • Plan for refactoring DOM APIs (JST)
• Complete ES4 spec and ref impl (Q207):
  • Graydon+Brendan
• Begin Tamarin/SM integration (Q307)
  • Extract GC from Tamarin (e.g. remove all fp dependencies) (??)
  • Ensure GC/Taramin compiles/runs on all platforms
• Rich Graphics Plan (Q207)
  • Video Prototypes (Chris D)
  • SVG/Canvas Plan (??)
  • Accelerated Graphics Plan (??)
  • OpenText Improvements Plan (Pav)
• Security Plan (Q207)
• Layout Plan (Q207)
• Finalize choice of VCS and implement

Timeline

• Q107 - Kickoff of project
  • VCS up and ready for checkins
  • Major areas of focus identified
  • Owners for each area identified
• Q207
  • ES4 Spec and Ref Impl Complete
  • Plans flushed out for each major task area
  • Refactoring checked in
• Q307
  • Tamarin GC Building on all major platforms
  • First proptype of Tamarin
  • Design/Prototypes done for each major area
• Q407
  • First Alpha of Moz2/Gecko2/FF4 released
• Q108
  • FF4 Alphas
  • All Major design work done
• Q208
  • First FF4/Moz2 Beta
• Q308
  • Betas
• Q408
  • Moz2/FF4 Ship

A Better VCS (Brendan/Preed)

See 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

• 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 [preed's Mortal Kombat] salute and look for news on his blog.

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.

ES4

• Ref implementation complete June 07
• Merge Tamarin in existing JS APIs
• Tamarin Performance Improvements (see above)
• JS Trust labels

By combining APIs, code, and ideas from SpiderMonkey and Tamarin, we will build a 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 that today's Tamarin in order to avoid certain pitfalls. We will probably need all of these:

• Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types).
• 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 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:

• Native compiler front end.

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 eval requirements (which will be novel to Flash in a future release).

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 XBL2, we may need to support data-tainting with static flow analysis as well as dynamic taint propagation.

Semi-automated refactoring work/Oink

Static Analysis via Oink will play an important role, we think, in partially or fully automating

• deCOMtamination, including getting XPCOM completely out of the middle of Gecko
• static data-tainting checks to uphold confidentiality properties
• conversion to 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 here. The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at another this blog post.

Embedding API Design

• Mozilla 2:Embedding APIs
• Mozilla 2:Obsolete APIs

Graphics/Advanced Rendering

• 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 3d transform

• Tighter integration between image decoding and rendering
  • decode-on-render
  • SVG as image