From http://www.chromium.org/developers/design-documents/oop-iframes
This is a plan document within the chromimu project and has not been put into practice. However, we can use it to learn about Google's ideas.
This article is a general description of our plan, as a site
Part of the isolation project.
Our goals include tracking IFRAME in multiple processes; calling and tracking scripts between processes; supporting cross-process navigation within a frame; and sending input events to the correct process.
Frame Overview
We expect to change the tab-Level Logic of chromimu to frame-level, so that each frame can exist in different processes.
Background In general, web pages with scripts calling each other must survive in the same process (if they are on the same site ), alternatively, you need a way to transmit messages to each other (if they are on different sites ). Chromium manages these relationships by placing all pages in the same browseringinstance object and grouping pages with the same browsinginstance object into siteinstance objects by site (in process
). Browsinginstance usually only contains one tab, but when a webpage uses window. when open or targeted link is enabled, it can also contain multiple tabs. it should be noted that browsinginstance does not know the number of tables in a window, because manually created tabs are in their own browsinginstance. To support cross-process interaction such as postmessage, chromium must save a "swapped out" version of domwindow in the browsinginstance of other processes as a proxy. For example, if a webpage of Site A can find a replaceable domwindow that represents the activity tab of Site B in its own process. This domwindow will pass postmessage to the corresponding page in the corresponding process of site B. For out-of-process iframes, chromium also needs to track the domwindow that can be switched out, just like the tab. The browser process is in the browser process. Chromium must track the entire frame tree for each tab. Webcontenst manages the frametreenode object tree, which corresponds to the frame tree of the current page. Each frametreenode will contain the frame information (such as the frame name). It will be responsible for cross-process navigation in the frame and support messages transmitted by other process frames. For each rendering process, chromium must track the donwindow of each frame in browsinginstance so that JavaScript code can locate the frame and send a message to them. We need to minimize the overhead of each domwindow. We plan to separate the frame-related logic from the renderview and renderviewhost classes of the content module and put them into a new renderfame and renderframehost classes. These new classes will be assigned their own remote IDs so that IPC messages can recognize them. We will provide an renderframe class for each active frame, and in the browsinginstance of other processes, we will provide a corresponding renderframe object that can be swapped out. Shows a browsinginstance that contains two tabs, each of which contains two sub-frames. These replaceable proxy objects are represented by dotted lines. Blink is inside blink. We hope to clearly distinguish the actual active frame and the convertible frame that only contains the proxy object. In terms of concept, an active frame contains a common domwindow and a document, while a convertible frame contains a remotedomwindow without a document. We plan to refactor the frame so that the document can be accessed only through the dowindow (removing the dependency directly on the document from the frame), which will affect a large part of the code. Using this method, we can use the "swappedout: //" url and IPC message filtering to eliminate the current convertible logic, because remotedomwindow will not have a document. This means that the code in blink cannot assume that the document can be completely traversed in a process. It may need to change Code such as editor and focus tracking. Note: We are investigating how to reduce the memory usage of these renderframe and domwindow objects, which will occupy more memory than the current chromium. Today, the memory requirement for a browsinginstance is O (tabs * processes), and most browsinginstance values include 1 to 2 tabs. The new model will require O (frames * processes ). This will use more memory. Because the frame attribute is much larger than the number of tabs, and the frame of different sites will increase more processes. Fortunately, there are many opportunities to reduce memory overhead. Navigation chromium supports cross-process navigation between sub-frames. Unlike now, if the rendering process intercepts all the navigation and determines whether the browser process is processed, the new model processes the navigation in the network stack of the browser process. If the navigation bar crosses the boundary of the site, the browser process exchanges the rendering process of the frame. The browser process can do this because it is made up of all the frame trees and determined at the upper layer. To achieve this, you need to adapt to the transfernavigationresourcethrottle object and give the IO thread sufficient information so that it can determine whether to exchange.
The history session of tab also makes rendering of the factor frame in different processes complicated. Currently, blink carefully tracks the Frame Tree in each historyitem in the rendering process, while the browser process uses navigationentry to only track each backward/forward entry. We will remove the frame tracking logic in blink's historycontroller and keep track of the navigation of each frame directly in the browser process.
We will use a method closer to the HTML5 standard to represent the historical Session of the tab. Compared to the practice of cloning the frame tree without any histroyitem, I will track the historical sessions of each frame in the browser process and use the separated "Joint Session history" list for the back and forward navigation. Each entry in the list uses a tree to point to the historical session corresponding to the frame.
Rendering to be able to render IFRAME and its parent page in different processes, the browser process transmits information between rendering processes, helping the GPU process render the image in the correct order and position. Also, the write logic may be adapted or partially used on browserplugin.
For the design of this part, see separate
Document
The input event is under investigation...
