Concrete Architecture of Gecko in Firefox 6 By

Concrete Architecture of Gecko in Firefox 6 By The Fully Optimized e. Xperience (FOX) James Brereton - 06069736 Katie Tanner - 06060472 Gordon Krull - 06003108 Rob Staalduinen - 06009513

Presentation Overview 1. 2. 3. 4. 5. 6. 7. 8. ◦ ◦ ◦ Introduction Derivation of Concrete Architecture Conceptual vs. Concrete Architecture Overview Document Parser Content Model Style System Frame Constructor Platform Specific Rendering and Widgets Updated use case diagram Limitations Lessons Learned Summary

Introduction � 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

Derivation of Concrete Architecture � 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

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

Document Parser � Unexpected Dependencies (Internal) ◦ Content Model �The HTML Parser needs access to HTML form constants and processes �Access to ns. Event. States. h in order to inform the content model of any Html changes within the parser. �Unexpected Dependencies (External) ◦ Display Backend �The Display Backend calls HTML 5 Parser. cpp and HTML 5 Stream. Parser. cpp to retrieve HTML 5 data ◦ UI Layer �UI Layer takes HTML code and converts it to plain text (ns. Scriptable. Unescape. HTML. cpp)

Content Model

Content Model � Unexpected Dependencies (Internal) ◦ Frame Constructor �ns. Tree. Utils. cpp and ns. Tree. Content. View. cpp, used for reading and interpreting the DOM Tree ◦ Platform Specific Rendering and Widgets �Puppet. Widget. cpp �Allows for widgetless rendering, acts as a place holder widget when no widgets are involved �ns. Android. Bridge. cpp and ns. App. Shell. cpp �When creating the DOM tree on the Android platform, if the web browser needs access to the GPS and other Hardware Functionality

Style System

Style System � Unexpected Dependencies (Internal) ◦ Content Model �Contains a large number of Style Rules and interfaces which are called on by ns. CSSRule. Processor. cpp ◦ Frame Constructor �Contains a large number of CSS objects, but files such as ns. Block. Frame. cpp and ns. IScrollable. Frame. cpp are also used by the Style System in the CSS Rendering Process ◦ Platform-Specific Rendering and Widgets �The style system’s Style. Consts. h file depends on various “Look and Feel” objects related to platformspecific rendering

Style System � Unexpected ◦ UI Layer Dependencies (External) �Dependency on ns. XULWindow. 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 ◦ Spider. Monkey �The Style System Depends on Spider. Monkey for fetching CSS properties (ns. CSSProperties. QS. h)

Frame Constructor

Frame Constructor � Unexpected Dependencies (Internal) ◦ Document Parser �ns. HTMLParts. h calls ns. HTMLContent. Sink. cpp ns. HTMLParts 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 ns. IPlugin. Widget. cpp for mac-specific frame rendering, and ns. Native. Widget. cpp which deals with platformspecific rendering

Frame Constructor � Unexpected ◦ Necko Dependencies (External) �Depends on frame constructor for handling URIs and Input/Output streams (ns. Net. Util. h) �Frame Constructor depends on Necko when secure browsing (ns. Secure. Browser. UIMPL. cpp) ◦ UI Layer �Toolkit file ns. App. Runner. cpp depends on Frame Constructor �Frame constructor depends on XPFE when dealing with XUL

Platform-specific Rendering and Widgets

Platform-specific Rendering and Widgets � Unexpected Dependencies (Internal) ◦ Style System �ns. Native. Theme. cpp and ns. Native. Theme. Win. cpp call upon ns. Style. Struct. h for internal style rules, and “Look and Feel” widgets call upon Style. Consts. h ◦ Content Model �Puppet. Widget. ccp calls Tab. Child. ccp � Comment inside Puppet. Widget. h: � // Tab. Child normally holds a strong reference to this Puppet. Widget //or its root ancestor, but each Puppet. Widget also needs a reference // back to Tab. Child (e. g. to delegate ns. IWidget IME calls to chrome) // So we hold a weak reference to Tab. Child (PBrowser. Child) here. // Since it's possible for Tab. Child to outlive the Puppet. Widget, // 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 ns. OSHelper. App. Service. 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 ns. App. Shell. CID. h in the UI layer (XPFE folder)

Updated Use Case (Rendering a Webpage –uncached)

Limitations � 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

Lessons Learned � 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

Summary 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

References � 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/mozillacentral/widget/src/xpwidgets/Puppet. Widget. h. html