Concrete Architecture of Firefox 6

By The Fully Optimized eXperience (FOX)
James Brereton - 06069736
Katie Tanner - 06060472
Gordon Krull - 06003108
Rob Staalduinen - 06009513
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
Lessons Learned
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
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
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
◦ 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
 Frame constructor depends on XPFE when dealing with
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
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
◦ We derived unexpected dependencies both within Gecko and
external to it.
Our derivation was limited due to poor documentation

similar documents