Table of Contents: 1. Abstract 2. Derivation Process 3. Alternative Architecture 4. Alternative Architecture 5. Conceptual Architecture 6. Sub Components 7. Dependencies 8. Use Case A 9. Use Case B 10.Team Issues 11.Lessons Learned 12.Conclusion 13.Sources Abstract The goal of this project is defining and understanding a conceptual architecture for the Google Chrome browser. Our team developed a conceptual architecture through research of developer documentation, video documentation/developer interviews, and observation of reference architectures of other browsers. Through research and analysis, our team has come to an agreement that Chromium’s architecture consists of a semi-strict layered design at the high level, and an object-oriented style at the lower level. Chromium’s architecture consists of different subsystems and subcomponents, which are defined in the report, as well as their interactions with each other and their purpose. Three use-case scenarios are also depicted to further characterize their interactions in standard browser use scenarios. The research and understanding developed through visualizing a conceptual architecture for Google Chrome will help pave the way to establishing a final concrete architecture for the popular web browser. Derivation Process Through the derivation process it was decided to work with the Mozilla Firefox architecture as it closest resembles the chromium architecture. Reading through the chromium developer documentation our team was able to get a thorough understanding of the material. The google developer videos were an excellent supplement to the documentation which bridged the gap with visual explanations and demonstrations. Bellow you can find a sample Mozilla FireFox conceptual architecture. Alternative Architecture As part of our derivation process, we decided to come up with a simplistic alternative architecture to expand on. To do this, we imagined the simplest way chrome could lay out a web page, so we could essentially figure out which dependencies are set in stone and likely to be present in our final architecture. Using this thinking, we came up with a strict layered architecture as shown in the figure below: This architecture uses many ideas from Chromium source documentation1 , but more importantly, makes sense intuitively. Browser: If you imagine the physical chrome browser itself, it’s easy to imagine it in a top down manner. At the very top is the Browser layer, which is responsible for any function that essentially can’t be handled by a tab, such as switching tabs. Due to this, the browser directly depends on tabs, which we have real evidence of: if you close your last open tab in chrome, your browser will close too. Web Contents: The tabs would be kept in in the Web Contents layer, which would control things such as navigation, and as well have the ability to talk up to browser to find out thing such as search 2 2 history . Due to this, the browser would implement a delegate ​ to allow Web Contents to ​ 1 http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome 2 https://www.youtube.com/watch?v=IiN9fxwjcL0&t=400s communicate with it, but Web Contents itself is not dependent on Browser, e.g you don't necessarily need a browser window to have a tab. The web contents layer is also responsible for sending messages to render host when something needs to be rendered. Render Host/Renderer: At this layer we start to see evidence of Chrome’s multi-process architecture. The Render Host lives in the browser process(along with Browser and Web Contents), where as the Renderer(s) would reside in the renderer process ( along with Blink wrapper and Blink). The Render Host receives messages from Web Contents and is responsible for identifying the right Renderer to send it to, as well as relaying the relevant rendering information3. These layers should know nothing about the Web contents or Browser, e.g you could detach theses layers 2 and re attach them to any browser that supports multiprocessing ​ . ​ Blink wrapper/blink: At the bottom layers we have the Blink Wrapper and Blink itself. Blink has its own abstract platform4 and thus would not have any dependencies within chrome, so in a strict layered architecture it must be at the bottom. It receives rendering messages from Render Host with help of the blink wrapper, which aids in communication and things such as type conversion 2 .​ Using this is a basis for component interaction within Chrome, we were able to come up with our final conceptual architecture 3 https://medium.com/@zicodeng/explore-the-magic-behind-google-chrome-c3563dbd2739 4 https://www.chromium.org/blink Conceptual Architecture: Sub-Components Blink: Blink is the rendering engine of google chrome, it is responsible for rendering almost all content inside a browser tab. It has the responsibility for implementing the HTML standard specs, including DOM, CSS and WebIDL. It is Since it does not render JavaScript by itself; it is embedded within V8 allowing it to render and process JavaScript pages. Due to its layered architecture, Blink is also responsible for requesting resources from the network stack. Relying on a multi-process architecture chrome has one dowser process which sandboxed rendered processes, where a certain number of memory addresses are reserved for the single process. Blink being a sub-process has to rely on the browser process for system calls and accessing user data. V8: Is a high-performance JavaScript and WebAssembly engine used for chrome which is entirely written in C++. Due to the nature of its architecture it can support multiple platforms from windows, OSX and Linux systems, implementing ECMAScript and WebAssembly. Its main responsibility is to compile and execute JavaScript code, ensuring memory allocation of objects, maximising performance. LibXML: Lib xml is a general XML parsing tool which helps compile and execute XML documents; written in C. Skia: Skia is a opensource graphics engine which works in conjunction with Blink in order to implement backend graphics for google chrome’s browser. It enables graphic rendering both using a given computer’s GPU or CPU; whichever is more efficient. Network Stack: Google chrome has a single-threaded network stack which ahs the main responsibility to interface URL requests and storing all the necessary information to fulfill URL requests such as cookies and cache. This architecture enables for cross platform abstractions; windows, OSX and Linux. Dependencies The user interface, or UI, is what the user directly sees and interacts with. The UI depends on two major components; the browser and the display backend. It depends on the Views subsystem (in the display backend) to acquire the general layout and interface of the current webpage. This subsystem depends on Skia, the graphics engine, to load in images, graphical objects, text, font, etc. to give the UI the visual content the user wants to see. The user interface also depends on the browser to be able to function. The browser engine enables the actual functionality of the web page, which is why it depends on the rendering engine, Blink. Within the browser we also have plugins and data persistence, which is information that is saved at the user’s permission to be accessed later (such as saved passwords and personal information, cookies, and history). The browser depends on the network component as well, because it communicates with the network stack to access information specific to the current webpage/website that the user is on. The rendering component contains the XML parser (libXML), and JavaScript Interpreter (V8). The rendering engine, Blink depends on these to be able to convert code into information that the browser engine information can intake, and then pass onto the UI to render and add functionality to the webpage. Blink is also dependant on Skia so that it can render content onto the webpage (using a bitmap). Blink also depends on the network, to communicate with the network stack to fetch page information and for general page loading. Use Cases Figure 1: Use case scenario for user successfully logging in to a website The user inputs a URL into the user interface. A URL request is sent to the browser, where it checks if the user-inputter URL is stored in the cache. In this situation, it is not, so the browser fetches the URL data from the network stack, and saves it in the cache. This URL data is then passed to the rendering engine, which then sends a call to render the page bitmap to the display backend subsystem. The display backend then proceeds to render any text, graphics, and layout information of the page, passes back a bitmap to the rendering engine, which then sends this to the browser. The browser subsystem sees a password text field, and checks the password database to see if any password is stored for this URL. In this scenario, a password is not saved in the browser database, so the UI displays the page to the user and prompts them to enter a password. Once the user inputs a password, the browser sends this password to the network stack to confirm that the user-inputted password is valid. The response is then sent back to the browser, which saves the inputted password in a database, and displays a successful password attempt message to the user. Figure 2: Use case scenario of Chrome rendering a page that contains JavaScript In this use-case example, a closer view of the rendering component is displayed, in order to conceptualize the process of displaying a page with embedded JavaScript. Much like the previous use-case scenario, the user enters a URL into the UI. This is passed to the browser, which checks to see if there is a saved version in the cache, which there is not.