By The Fully Optimized eXperience (FOX)
James Brereton - 06069736
Katie Tanner - 06060472
Gordon Krull - 06003108
Rob Staalduinen - 06009513
1.
2.
3.
4.
5.
6.
7.
8.
◦
◦
◦
◦
◦
Introduction
Derivation of Concrete Architecture
Conceptual vs. Concrete
Concrete Architecture Overview
Document Parser
Content Model
Style System
Frame Constructor
Platform Specific Rendering and Widgets
Updated use case diagram
Limitations
Lessons Learned
Summary



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




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

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

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)

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

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 platformspecific rendering

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)

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 framestate 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 platformspecific rendering

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

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()

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)

As a result of rapid evolution, there is little
documentation and comments in the source
code are often not informative or nonexistent
◦ 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


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



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









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_Embedding_
Basics
https://developer.mozilla.org/en/Gecko_FAQ
https://bugzilla.mozilla.org/show_bug.cgi?id=67961
5
http://wwwarchive.mozilla.org/newlayout/doc/layout-2006-1214/master.xhtml
https://wiki.mozilla.org/Frame_inheritance_hierarchy
http://dxr.mozilla.org/mozilla/mozillacentral/widget/src/xpwidgets/PuppetWidget.h.html