Eyes Above The Waves

For quite a while now, Firefox 3.6 has been done as far as most Gecko work is concerned. Meanwhile all kinds of exciting things are happening on trunk, but we haven't been blogging enough about them. I'll try to do that a bit more starting today, and I encourage my colleagues to do the same!

Since it was first designed, Gecko has supported multiple presentations per document (in code terms, multiple nsIPresShells per nsIDocument). The idea is that you would be able to have multiple views of the same document, each with different style sheets and layouts, and display and even edit the views simultaneously and have them all stay in sync. It sounds cool, and the idea also appears in the DOM specs (see document.defaultView), but the reality is that there is no need for this feature in Web browsers, as Dave Hyatt pointed out a long time ago. (Different views into the same presentation --- e.g., live thumbnails --- are useful, but that's a different and much simpler feature.) Supporting multiple presentations just adds unnecessary complexity.

The only use of multiple presentations in Gecko was for printing and print preview. When printing or previewing a document, we'd create a temporary extra presentation. But for printing you don't need a new presentation for the same document, it's fine to make a copy of the document and create a presentation for the copy. In fact this is a better approach, because you can print or display a preview while continuing to change the original document. You don't want to be displaying a print preview while a script keeps making changes to the document; apart from not being what the user wants, we never supported such dynamic changes properly, so we had to carefully freeze scripting while a print preview was displayed. This was complex and fragile.

Thanks to Olli Pettay this is all history now. He went ahead and implemented the document copying approach for printing and print preview. This approach let us fix a lot of bugs more easily. For example, we can take a snapshot of the current frame of each animated image --- and video, and plugins --- when copying the document, so the copy is truly static (although you can still change the layout, e.g. by changing the page margins). We don't have to worry about temporarily freezing scripts --- we just disable scripting altogether in the copied document.

Better still, this let Olli go ahead and remove the support for multiple presentations. This lets us do various simplifications and optimizations. In particular, before, each presentation had a hash table mapping elements to their "primary frames" used for rendering that element in that presentation. Now a DOM element can have a direct pointer to its primary frame. This is more efficient and also lets us use much simpler code since we no longer need to maintain primary frame maps.

In general there are lots of places in our code where we used to have to think "am I using the right presentation for this document"? We no longer have to think about that.

One architectural misfeature eliminated. Stay tuned for more :-).