By The Fully Optimized eXperience (FOX) James Brereton Katie Tanner Gordon Krull Rob Staalduinen

1. Introduction 2. Derivation of Concrete Architecture 3. Conceptual vs. Concrete 4. Concrete Architecture Overview ◦ Document Parser ◦ Content Model ◦ Style System ◦ Frame Constructor ◦ Platform Specific Rendering and Widgets 5. Updated use case diagram 6. Limitations 7. Lessons Learned 8. 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 platform- specific 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 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

 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 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

 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

    Basics Basics    archive.mozilla.org/newlayout/doc/layout /master.xhtml archive.mozilla.org/newlayout/doc/layout /master.xhtml   central/widget/src/xpwidgets/PuppetWidget.h.html central/widget/src/xpwidgets/PuppetWidget.h.html