Gecko 1.9 Roadmap
Introduction to the Gecko 1.9 Roadmap
This roadmap describes the planned capabilities of the Mozilla platform, often known as "Gecko", in the 1.9 release. The primary product delivery vehicle for this platform is Firefox 3, which will be explored, discussed, and refined elsewhere, likely in a manner similar to that employed for Firefox 2. There are several major areas of development for Gecko 1.9, intended to serve both the applications built on top of it (chiefly Firefox 3) and applications built on the web which need or would benefit from improvements in web technology. Many of these web-facing enhancements will be implementations of existing standards, in whole or in part. Some will be new standards.
The work described in this document will be performed – in several cases it is already being performed, as of February 2006 – on the trunk of Mozilla CVS, with the 1.8 branch preserved largely intact. Some of the features listed below may be pulled forward into that 1.8 branch if needed for product releases off that branch, but you shouldn't count on it. We will preserve all API (declared-frozen or not) compatibility on the 1.8 branch, so only selected additional APIs are thinkable. (A Gecko 1.8 Roadmap is also needed, and it should be expected to describe the criteria by which necessarily-API-compatible changes may be selected for promotion to the 1.8 release stream.)
Much more information on the management of these branches, and post-1.8.0 releases of Gecko 1.8, is available in the branch plan. Firefox3/Gecko Feature List tracks the development status of Gecko 1.9 features; Gecko 1.9 alpha was released as "Gran Paradiso" in December 2006.
Readers of this document will notice a conspicuous absence of bug lists, detailed schedules, or decomposition of development work into individual tasks. While this roadmap is intended to provide a statement of direction for the platform in Gecko 1.9, responsibility for detailed planning of such areas of development is necessarily devolved to the groups doing – or, in the case of some larger tasks, leading – the design, development, and testing of specific capabilities. We seek here to make clear the "whats" and "whys", but not to elaborate in meaningful detail on the "hows" or "whens".
As this roadmap describes the future, and not history, some revision is to be expected. The delineation of "planned" and "desired" work is hopefully made clear below; for work to be considered "planned", there should be credible understanding of the "hows" and "whens", as well as clear commitment of the "whos". We strongly encourage the leaders of such "planned" work to record their understanding in a public document, and keep it updated and linked from appropriate project pages.
The owner of record for this document is Mike Shaver (firstname.lastname@example.org), and all errors or omissions within it are first and foremost his responsibility. Brendan Eich (email@example.com) continues to drive the vision and architecture of the platform in the large, and his influence on the platform roadmap is both significant and indispensible. In the case of a tie, disputes will be settled by single combat.
Graphics and layout capabilities
Graphics and layout changes represent some of the most invasive work proposed for the Gecko 1.9 development cycle. They form the core of the architectural shifts in 1.9, and are considered to be the most difficult and riskiest elements.
To manage risk, this roadmap has proposed that major graphics and layout work – especially the cairo-substrate and reflow-branch changes – be scheduled as early as possible, in staged landings. The work required to make cairo the default graphics subsystem on the trunk is nearing completion as of this writing (February 2006), and the reflow branch has also shown significant progress, but both will require significant and risky additional work before they can be laid to rest, and we continue to recommend that this work and risk be front-loaded in the Gecko 1.9 schedule.
cairo Graphics Substrate
We plan to replace our aging and limiting graphics ("gfx") infrastructure with the cairo 2D graphics library. The aim of shifting to cairo is to bring modern, hardware-accelerated 2D graphics capabilities to the whole of the web, without requiring proprietary plugins or rendering obsolete the broad and rich set of web authoring techniques developed over the past decade. This change will have as a side-effect the dropping of support for Windows versions prior to Windows 2000 (such as Windows 95, 98, and ME); we believe that this is an appropriate and acceptable cost to bear in order to overcome the limitations of our current gfx model and the rendering capabilities exposed to the web.
The SVG support shipped in Firefox 1.5 has proven useful and valuable, but we know – and knew before 1.5 shipped – that it can be made much more so. Features such as filters, text pathing and foreign objects are high on the list, but all of SVG 1.1 is in scope for Gecko 1.9.
The layout changes – see also the "XUL' and XBL2" section of this roadmap – center around David Baron's "reflow branch", the aim of which is to eliminate reflow commands and types, and significantly reduce the complexity of the Gecko layout model. This is the first change to global layout architecture in several years, and it is hoped that it will address many problems related to incremental reflow. In addition, it should simplify some problems that are not practically soluble with the current architecture, such as support for inline-table.
The <canvas> element was another graphical highlight of the Firefox 1.5 release, and we intend to improve it in Gecko 1.9. In addition to substantial performance improvements, we are investigating text support and a 3D context.
As the success of canvas and SVG have shown, additional graphical capabilities are very welcome on the leading edge of web development, especially where they interoperate well with other web content and permit authors and developers to provide fallback options for lesser, weaker user agents. We are investigating the addition of some key, easy-to-use 2D graphics capabilities to the XUL language, with similar criteria of righteousness and towards similar ends.
Apart from all the new language features (for more details, stay tuned to the roadmap blog), the JS2 implementation should be significantly faster and easier to debug, both from script and from a graphical debugger such as Venkman. Debugging support in major IDEs is possible (more than possible in one IDE that's already working on it).
We hope to have a credible implementation plan for JS2 published early second quarter of 2006, with prioritization of various Edition 4 features as they are drafted by the Technical Group. Please do not mistake the current vagueness for a lack of commitment to providing important JS2 features as part of Gecko 1.9!
Python for XUL
(But see caveats about glue distribution and API compatibility!)
Mark Hammond's work on PyXPCOM and a language-neutral DOM is well under way as of October 2005, and we believe that the glue code and bindings will be slim enough to be part of a default XULRunner or Firefox distribution when the 1.9 cycle is complete. We will need to determine which versions of Python we can support with common glue, as API compatibility story may not be all we hope for.
(N.B.: Mozilla does not intend to distribute the C-Python runtime with its applications or frameworks, so application developers who wish to take advantage of these capabilities will need to provide for this dependency in their installers or packaging. The desired stub or streaming installer capabilities in the Firefox/XULRunner based on Gecko 1.9 would probably help a great deal to ease the extra download for Python-less users.)
XUL' and XBL2
The XUL and XBL languages have served Mozilla development very well, and are often taken as a model for XML-based UI development in other circles. In some cases, however, our implementations or their old specifications are incomplete, inconsistent, insufficiently robust, or not amenable to some important use cases (including remote XUL applications or rich mixing with other content types such as HTML or SVG). We seek to address these limitations, and generally improve the XUL and XBL development experience, with work in Gecko 1.9.
XUL work in Gecko 1.9 will not undertake to create a shining XUL2 jewel, but will instead work to preserve compatibility with "XUL1" where practical, and make clean breaks where unavoidable. Hence the tentative name XUL' (XUL Prime).
The XBL work is based on an existing design by Ian Hickson and David Hyatt, currently being developed in the mozilla-xbl list. Pending the complete specification, we can't be sure that all of XBL2 will be implemented in the 1.9 timeframe, but we are committed to at least an improved attachment model, clearer lifecycle semantics, and scripting language neutrality. These are prerequisites for desired 1.9-era application and platform features.
XUL box model rationalization
Improvements to the XUL box model, based on the specification work started by Hixie and Hyatt, should provide a more consistent and flexible layout model for XUL developers, and help to rationalize XUL's interactions with other content types. This box-model work has been proposed for standardization via the W3C CSS working group. Much of the gain in any "shining XUL2 jewel" plan would likely be delivered by these box-model fixed, improvements, and cross-content rationalization, rendering the former not only a non-goal but also a non-issue.
Improved XUL/HTML interoperability and commonality
It is currently much more difficult and hazardous than it should be to mix XUL and HTML content freely, and several XUL elements have functionality which is frustratingly similar to that available in HTML. We wish to improve the usability of mixed XUL/HTML content, and reduce code size and bug habitat by implementing XUL in terms of HTML (or vice versa; c.f. the erstwhile XBL-form-elements work) where feasible.
Web app deployment and capability improvements
The recent resurgence in Web application development has demonstrated the significant power and capability of Web technologies, as well as some key areas of desirable improvement.
Chief among these areas of improvement is a client-local storage capability, which need is not sufficiently addressed by HTTP cookies. Cookies provide limited storage space (on the order of a few kilobytes), require the application developer to manually encode and decode any structure more complex than a simple string, and are transmitted back to the server on each request. In response to these limitations, some application developers are using the Flash plugin simply to gain access to a reliable and capable local store. Ian Hickson and the WHATWG have specified a simple but powerful client-local storage interface that addresses these concerns, and eliminates the dependence on proprietary plugins.
Another limitation often decried by developers of rich Web applications is the lack of a reasonable offline execution model. Mechanisms to remedy this lack include: facility to pin sets of pages for offline use; a mechanism for detecting that the application is running offline; and events to signal that the user is going offline or returning to online operation. Taken together with the aforementioned client-local storage system, these mechanisms would combine to enable a number of improved and important web experiences.
Embedding and application deployment
Internal/External API Convergence
For many application developers, putting Mozilla technology inside or underneath their applications has been a bittersweet experience. While they are rightly excited to have the power of the Mozilla platform at their disposal, the state of our embedding interfaces and application-launch facilities have created significant impediments to their productivity, and introduced expensive fragility into their environments. While we wish to see the plight of these developers improve, we do not believe that the "second-class" nature of 3rd party applications can be entirely wiped from our world.
Instead, we will make our own applications use the same interfaces that we recommend for embedders, in both C++ Gecko interaction and the XUL widgetry that is composed above it. Over time, we seek to drive the number of "embedding bugs", as distinct from "bugs that break our apps", to near-zero by improving alignment and overlap between those domains.
Developers who wish to build "on top" of our technology, rather than "around" it as in the common embedding case, are no less in need of our attention. For launching applications atop our platform, we will improve and promote XULRunner, and use it to launch Firefox and our other applications.
Embedding APIs, widgets, and frameworks
To further improve the coverage and reliability of our offerings to these developers, the embedding interfaces appropriate to each platform will be built and distributed as part of XULRunner, and therefore Firefox. These embedding interfaces include an ActiveX control on Windows, gtkmozembed on GTK-based platforms, and the embedding widget currently provided by Camino on Macintosh systems.
Miscellaneous platform improvements
In addition to the above new and enhanced capabilities, there are several important areas of improvement that resist even the preceding attempt at categorization. They are no less important for that mismatch.
Extension management improvements
Extensions have proven to be a very valuable mechanism for extending and improving Firefox and other "toolkit" applications. More sophisticated dependency handling, streaming or stubbed install, and cross-application extension management will be combined with support for additional types of extensions such as language packs and search tools. Combined with application-level improvements in overlay-point freezing and other such advancements, these should provide significant benefits to developers of extensions to Gecko 1.9-hosted applications.
Gecko 1.8 is accessible on Windows platforms using screen readers, screen magnifiers and other assistive technologies. Work is scheduled for accessibility of content and UI which utilize Gecko 1.9 on Linux and UNIX.
Security model improvements
The security model for web content relies on careful management of trust labels, the mixing of which has long been known to security researchers as a source of significant danger. Also, Gecko's support for content with elevated privileges, derived from the Java privilege model from the time of Netscape 4, does not sufficiently distinguish between web applications that can be trusted not to spoof application UI or attempt to "drive by" extension installation, and those that seek to run arbitrary code on the host machine or perform unrestricted operations on the local filesystem. Building on successful research from the programming-language security community; lessons from Java and .NET; and our own person-centuries of experience building and reinforcing web security models, we seek to provide a richer and more reliable model of trusted execution, and especially "partially-trusted" execution.
Event queue rearchitecture
The current model of nesting event queues in order to simulate modality is fraught with peril, and is responsible for many hard-to-fix problems with responsiveness and concurrency. Darin Fisher and others propose to eliminate the nesting model, for the good of all.