With same-site BFCache enabled every navigation can now potentially be served
via the BFCache. To support this internally a new top-level RenderFrame object
may be created for each new navigation. As a result, OnBrowserCreated may now
be called multiple times with the same browser ID in a given renderer process
(a behavior previously only seen with cross-site navigations and different
renderer processes).
BFCache navigations do not trigger the same Chromium notifications as a normal
load. To avoid breaking CEF API usage expectations we now synthetically
generate the load-related callbacks that would otherwise be missing
(OnLoadingStateChange with isLoading=true, OnLoadStart, OnLoadEnd). The
|httpStatusCode| argument to OnLoadEnd will be 0 in this case.
To test:
- Run `FrameHandlerTest.*:MessageRouterTest.*:NavigationTest.*`
- Run `NavigationTest.LoadSameOriginLoadURL` for OnBrowserCreated behavior.
- Run `NavigationTest.History` for load-related callback behavior.
The mojo channel used for frame communication may disconnect for a variety of
reasons including frame navigation, frame destruction, or insertion into the
BackForwardCache (when the browser-side frame representation is destroyed and
closes the connection). When disconnect occurs we now evaluate the situation
and reconnect if appropriate.
Connections are now initiated solely from the renderer process and the
RenderFrame is passed as an argument to FrameAttached() instead of being
retrieved independently. Messages are queued while the frame is disconnected
and sent only after FrameAttachedAck() is received from the browser process.
The renderer process will be crashed intentionally with a "connection retry
failure" message if the reconnect fails 3 times in a row.
See the new cef_frame_handler.h for complete usage documentation.
This change includes the following related enhancements:
- The newly added CefBrowser::IsValid method will return false (in the browser
process) after CefLifeSpanHandler::OnBeforeClose is called.
- CefBrowser::GetMainFrame will return a valid object (in the browser process)
until after CefLifeSpanHandler::OnBeforeClose is called.
- The main frame object will change during cross-origin navigation or
re-navigation after renderer process termination. During that time,
GetMainFrame will return the new/pending frame (in the browser process) and
any messages that arrive for the new/pending frame will be correctly
attributed in OnProcessMessageReceived.
- Commands to be executed in the renderer process that may fail during early
frame initialization (ExecuteJavaScript, LoadRequest, etc.) will now be
queued until after the JavaScript context for the frame has been created.
- Logging has been added for any commands that are dropped because they arrived
after frame detachment.
This change introduces a few minor CEF API behavior changes:
- A CefProcessMessage object cannot be reused after being passed to
SendProcessMessage.
- The |extra_info| argument to CefRenderProcessHandler::OnBrowserCreated may
now be NULL.
Where appropriate, we now utilize the default UTF string encoding format and
shared memory to reduce copies and conversions for the cross-process
transfer of arbitrary-length strings. For example, CefFrame::GetSource/GetText
now involves zero UTF conversions and zero copies in the browser process for
the CefString delivered to CefStringVisitor::Visit().
This change moves the SendProcessMessage method from CefBrowser to CefFrame and
adds CefBrowser parameters to OnProcessMessageReceived and
OnDraggableRegionsChanged.
The internal implementation has changed as follows:
- Frame IDs are now a 64-bit combination of the 32-bit render_process_id and
render_routing_id values that uniquely identify a RenderFrameHost (RFH).
- CefFrameHostImpl objects are now managed by CefBrowserInfo with life span tied
to RFH expectations. Specifically, a CefFrameHostImpl object representing a
sub-frame will be created when a RenderFrame is created in the renderer
process and detached when the associated RenderFrame is deleted or the
renderer process in which it runs has died.
- The CefFrameHostImpl object representing the main frame will always be valid
but the underlying RFH (and associated frame ID) may change over time as a
result of cross-origin navigations. Despite these changes calling LoadURL on
the main frame object in the browser process will always navigate as expected.
- Speculative RFHs, which may be created as a result of a cross-origin
navigation and discarded if that navigation is not committed, are now handled
correctly (e.g. ignored in most cases until they're committed).
- It is less likely, but still possible, to receive a CefFrame object with an
invalid frame ID (ID < 0). This can happen in cases where a RFH has not yet
been created for a sub-frame. For example, when OnBeforeBrowse is called
before initiating navigation in a previously nonexisting sub-frame.
To test: All tests pass with NetworkService enabled and disabled.
Requests created using CefURLRequest::Create are not associated with a
browser/frame. When originating from the render process these requests cannot be
intercepted and consequently only http(s) and blob requests are supported. To
work around this limitation a new CefFrame::CreateURLRequest method has been
added that allows the request to be associated with that browser/frame for
interception purposes.
This change also fixes an issue with the NetworkService implementation where
redirected requests could result in two parallel requests being sent to the
target server.
To test: URLRequestTest.* tests pass with NetworkService enabled.
Marshall Greenblatt
Alexander Guettler