Give the main frame a RenderWidget.
Currently, RenderView is a subclass of RenderWidget, and the RenderWidget
portion is effectively treated as the the widget for the main frame as
well. For a number of reasons, this is a problematic model:
- A remote frame doesn't need a widget; however, a RenderView with a remote
main frame still has a vestigal RenderWidget.
- Code that needs to affect both RenderWidget / RenderView is awkwardly
split between them, in both content and blink.
- RenderView itself is often seen as an easy entry point to perform
page-level work in the renderer. With OOPI, this is no longer a valid
assumption.
In order to incrementally de-widgetize RenderView, the main frame will
have also have a RenderWidget, to make it consistent with the local frame
roots for subframes, which already have a RenderWidget. However, instead of
giving main frames their own RenderWidget, the main frame re-uses the
RenderView as its RenderWidget.
The rationale for taking this approach is to minimize the breakage: today,
Chrome simply doesn't expect to have two "widgets" for a frame.
Instantiating a distinct RenderWidget for the main frame can confuse code
that iterates or counts the active widgets: an example of this is the
security check for injecting WebUI bindings.
In the future, when RenderViewHost has-a RenderWidgetHost (and similarly,
when RenderViewImpl has-a RenderWidget) instead of today's is-a relation,
then it be conceptually much more straightforward to transition completely
to the new model.
BUG=419087
Review URL: https://codereview.chromium.org/1303773002
Cr-Commit-Position: refs/heads/master@{#356176}
diff --git a/content/browser/security_exploit_browsertest.cc b/content/browser/security_exploit_browsertest.cc
index 2c5acc4..1358af2 100644
--- a/content/browser/security_exploit_browsertest.cc
+++ b/content/browser/security_exploit_browsertest.cc
@@ -196,7 +196,7 @@
// process.
IN_PROC_BROWSER_TEST_F(SecurityExploitBrowserTest,
AttemptDuplicateRenderViewHost) {
- int duplicate_routing_id = MSG_ROUTING_NONE;
+ int32_t duplicate_routing_id = MSG_ROUTING_NONE;
RenderViewHostImpl* pending_rvh =
PrepareToDuplicateHosts(shell(), &duplicate_routing_id);
EXPECT_NE(MSG_ROUTING_NONE, duplicate_routing_id);
@@ -213,10 +213,12 @@
scoped_refptr<SessionStorageNamespaceImpl> session_storage(
new SessionStorageNamespaceImpl(dom_storage_context));
// Cause a deliberate collision in routing ids.
- int main_frame_routing_id = duplicate_routing_id + 1;
- pending_rvh->CreateNewWindow(duplicate_routing_id,
- main_frame_routing_id,
- params,
+ int32_t main_frame_routing_id = duplicate_routing_id + 1;
+ // TODO(avi): This should be made unique from the view routing ID once
+ // RenderViewHostImpl has-a RenderWidgetHostImpl. https://crbug.com/545684
+ int32_t main_frame_widget_routing_id = duplicate_routing_id;
+ pending_rvh->CreateNewWindow(duplicate_routing_id, main_frame_routing_id,
+ main_frame_widget_routing_id, params,
session_storage.get());
// If the above operation doesn't cause a crash, the test has succeeded!
