Concrete Architecture of Gecko in Firefox 6

By The Fully Optimized eXperience (FOX)James Brereton - 06069736

Katie Tanner - 06060472Gordon Krull - 06003108

Rob Staalduinen - 06009513

1. Introduction2. Derivation of Concrete Architecture3. Conceptual vs. Concrete4. Concrete Architecture Overview

◦ Document Parser◦ Content Model◦ Style System◦ Frame Constructor◦ Platform Specific Rendering and Widgets

5. Updated use case diagram6. Limitations7. Lessons Learned8. Summary

Presentation Overview

Gecko primarily acts as the browser and rendering engine for Firefox

It is responsible for parsing and compiling data received from Necko and rendering the webpage at the user’s request

The overall architecture of the Gecko subsystem is an object-oriented

Introduction

Our conceptual architecture of Firefox, created in the first deliverable of the project, acted as a starting point for our concrete architecture

We then began looking at the source files using lsedit and sorted files and folders into subsystem entities

We then examined unexpected dependencies to derive their root causes using lsedit and by viewing the source code

We attempted to determine if dependencies were caused by a misplaced file or were an inherent dependency within Gecko

Derivation of Concrete Architecture

Gecko Conceptual Architecture

Gecko Concrete Architecture

Conceptual vs. Concrete Removal of Image Library subsystem

◦ While moving files and looking for the contents of our entities, it became apparent that while documentation references an image library, actual tasks of uploading handling image data are handled by other subsystems

Many more internal dependencies

Document Parser

Unexpected Dependencies (Internal)◦ Content Model

The HTML Parser needs access to HTML form constants and processes

Access to nsEventStates.h in order to inform the content model of any Html changes within the parser.

Unexpected Dependencies (External)◦ Display Backend

The Display Backend calls HTML5Parser.cpp and HTML5StreamParser.cpp to retrieve HTML 5 data

◦ UI Layer UI Layer takes HTML code and converts it to plain text

(nsScriptableUnescapeHTML.cpp)

Document Parser

Content Model

Unexpected Dependencies (Internal)◦ Frame Constructor

nsTreeUtils.cpp and nsTreeContentView.cpp, used for reading and interpreting the DOM Tree

◦ Platform Specific Rendering and Widgets PuppetWidget.cpp

Allows for widgetless rendering, acts as a place holder widget when no widgets are involved

nsAndroidBridge.cpp and nsAppShell.cpp When creating the DOM tree on the Android platform, if

the web browser needs access to the GPS and other Hardware Functionality

Content Model

Style System

Unexpected Dependencies (Internal)◦ Content Model

Contains a large number of Style Rules and interfaces which are called on by nsCSSRuleProcessor.cpp

◦ Frame Constructor Contains a large number of CSS objects, but files such

as nsBlockFrame.cpp and nsIScrollableFrame.cpp are also used by the Style System in the CSS Rendering Process

◦ Platform-Specific Rendering and Widgets The style system’s StyleConsts.h file depends on

various “Look and Feel” objects related to platform-specific rendering

Style System

Unexpected Dependencies (External)◦ UI Layer

Dependency on nsXULWindow.cpp◦ Display Backend

The Style System depends on files for dealing with Font Metrics, and the display backend relies on the style system for font constants to avoid duplicated code

◦ SpiderMonkey The Style System Depends on SpiderMonkey for

fetching CSS properties (nsCSSPropertiesQS.h)

Style System

Frame Constructor

Unexpected Dependencies (Internal)◦ Document Parser

nsHTMLParts.h calls nsHTMLContentSink.cpp - nsHTMLParts retrieves HTML data from the content sink used for the content model for additional frame-state bits used by the Frame Constructor

◦ Platform Specific Widgets Contains a large number of widgets such as

nsIPluginWidget.cpp for mac-specific frame rendering, and nsNativeWidget.cpp which deals with platform-specific rendering

Frame Constructor

Unexpected Dependencies (External)◦ Necko

Depends on frame constructor for handling URIs and Input/Output streams (nsNetUtil.h)

Frame Constructor depends on Necko when secure browsing (nsSecureBrowserUIMPL.cpp)

◦ UI Layer Toolkit file nsAppRunner.cpp depends on Frame

Constructor Frame constructor depends on XPFE when dealing

with XUL

Frame Constructor

Platform-specific Rendering and Widgets

Unexpected Dependencies (Internal)◦ Style System

nsNativeTheme.cpp and nsNativeThemeWin.cpp call upon nsStyleStruct.h for internal style rules, and “Look and Feel” widgets call upon StyleConsts.h

◦ Content Model PuppetWidget.ccp calls TabChild.ccp

Comment inside PuppetWidget.h: // TabChild normally holds a strong reference to this PuppetWidget //or its root ancestor, but each PuppetWidget also needs a

reference // back to TabChild (e.g. to delegate nsIWidget IME calls to chrome) // So we hold a weak reference to TabChild (PBrowserChild) here. // Since it's possible for TabChild to outlive the PuppetWidget, // we clear this weak reference in Destroy()

Platform-specific Rendering and Widgets

Unexpected Dependencies (External)◦ Android-specific rendering files created a few

unexpected dependencies external to Gecko i.e., a dependency on Necko: Android Bridge depends

on nsOSHelperAppService.cpp in the uriloader folder for Android

Security and networking files in Necko specific to Android also depend on the Android Bridge file

◦ Widget support files depend on nsAppShellCID.h in the UI layer (XPFE folder)

Platform-specific Rendering and Widgets

Updated Use Case(Rendering a Webpage –uncached)

As a result of rapid evolution, there is little documentation and comments in the source code are often not informative or non-existent◦ Additionally, file naming conventions were not

useful in determining which subsytem a file belonged to

Difficult to collaborate effectively because changes to the architecture in lsedit could only be reflected on one instance of the file

Limitations

Meaningful comments are crucial to the understanding of the functionality of and relations between files and subsystems

Although we initially assumed that the data flow and purpose of each subsystem would be clearly defined, we found that subsystems contained files that were called beyond their initial scope, resulting in unexpected dependencies

Lessons Learned

Our derived concrete architecture for Gecko consists of a object-oriented style of architecture containing 5 subsytems, one less than our conceptual architecture

Although Gecko generally implements the object-oriented style that we expected, its derived dependencies reveal higher complexity than expected

The concrete architecture of Gecko contained many dependencies we did not expect when deriving our conceptual architecture. We believe that most of these exist for reasons of expediency, but this was difficult to determine for sure due to missing or unclear documentation.◦ We derived unexpected dependencies both within Gecko and

external to it. Our derivation was limited due to poor documentation

Summary

http://dxr.mozilla.org/mozilla/index.html https://wiki.mozilla.org/Gecko:Home_Page https://wiki.mozilla.org/Gecko:Overview https://developer.mozilla.org/en/Gecko_Emb

edding_Basics https://developer.mozilla.org/en/Gecko_FAQ https://bugzilla.mozilla.org/show_bug.cgi?id

=679615 http://www-archive.mozilla.org/newlayout/d

oc/layout-2006-12-14/master.xhtml https://wiki.mozilla.org/Frame_inheritance_h

ierarchy http://dxr.mozilla.org/mozilla/mozilla-central

/widget/src/xpwidgets/PuppetWidget.h.html

References