Mozilla 2: Difference between revisions

(See [[Mozilla_2/Old_Moz2|the 2004-era Mozilla 2 pages]] for older ideas.)

== Project Status ==

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

=== Work List ===

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

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

=== 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:

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

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

* 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

=== Anti-Goals ===

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

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.

==== Tasklist ====

* Complete ES4 spec and ref impl (Brendan/Graydon)

* Begin Tamarin/SM integration

** Extract GC from Tamarin - remove all flash deps (TBH)

** Ensure GC/Taramin compiles/runs on all platforms (TBH)

** [[XPCOMGC]] object model

* Rich Graphics Plan

** Video Prototypes (Chris D)

** SVG/Canvas Plan (Vlad)

** OpenText Improvements Plan (Pav)

* Security Plan (Window)

* Layout Plan (Roc/DBaron)

* Q107 - Kickoff of project

** VCS up and ready for checkins

* Q307

** ES4 Spec and Ref Impl Complete

*** Elimination of raw pointers

*** Shift to STD C++

* Q407

** Tamarin GC Building on all major platforms

** First prototype of Tamarin

** Design/Prototypes done for each major area

* Q108

** First Alpha of Moz2/Gecko2/Fx4 released

* Q208

** Fx4 Alphas

** All Major design work done

* Q308

** First Fx4/Moz2 Beta

* Q408

** Betas

* Q109

** Moz2/Fx4 Ship

* decentralized operation (no master repository with slave workareas)

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

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.

* Tamarin Performance Improvements (see above)

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:

* 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 [[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:

* 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 <code>eval</code> 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 [http://www.w3.org/TR/XBL 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 [[FirefoxSummit/2006/ProposedSessions/Oink|Oink]] will play an important role, we think, in partially or fully automating

* static data-tainting checks to uphold confidentiality properties

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

* [[Mozilla 2/XPCOM and Binary Embedding]]

* [[Mozilla 2:Embedding APIs]]

* [[Mozilla 2:Obsolete APIs]]

==== Rendering Performance ====

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

==== Security ====

* attack surface reduction

* content restrictions, <noscript>, jail

* next level private browsing

* low privilege/protected mode, cross platform

* xbl2

* security review for every feature lightweight process to make it manageable

* offline stuff

* profile encryption

* identity management

* platform native keychain

* all critical – moderate resolved through every major release