4855222c31
Change-Id: I1e04a88d497be7d26a6531e193ce5ba74da60d14 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2764612 Commit-Queue: Dirk Pranke <dpranke@google.com> Reviewed-by: Dirk Pranke <dpranke@google.com> Cr-Commit-Position: refs/heads/master@{#863564}
2.1 KiB
What is RenderDocument?
TL;DR
Chrome currently switches to a new RenderFrameHost when loading a new document if the render process is different to the previous one. The RenderDocument project is about making the switch to happen unconditionally. This:
- Eliminates the logic for navigating inside the same RenderFrameHost
- Makes RenderFrameHost in the browser process 1:1 with the Document.
- Prevents security bugs, e.g. reusing the data/capabilities from the wrong document.
Details
Previously when we navigate a frame from one page to another, the second page may appear in a new RenderFrame or we may reuse the existing RenderFrame to load the second page. Which happens depends on many things, including which site-isolation policy we are following and whether the pages are from the same site or not. With RenderDocument, the second page will always use a new RenderFrame (excluding navigation within a document).
Also when reloading a crashed frame we reused the browser-side RenderFrameHost. With RenderDocument we create a new RenderFrameHost for crashed frames.
Read more
high-level view of the work needed
discussion of how we can land it safely
Stages
We have 3 stages that are behind flags.
- crashed-frames:
A new
RenderFrameHostis used for reloading a crashed document. - subframes:
A new
RenderFrameHostis used for every nested document. - main frames:
A new
RenderFrameHostis used for every document.
Test changes
RenderFrameHost reference becomes invalid
Enabling this for subframes and main frames causes many tests to fail. It is common for tests to get a reference to a RenderFrameHost and then navigate that frame, assuming that the reference will remain valid. This assumption is no longer valid. The test needs to get a reference to the new RenderFrameHost, e.g. by traversing the frame tree again.