Chromium supports communication with media devices on the local network via
the Cast and DIAL protocols. This takes two primary forms:
1. Messaging, where strings representing state information are passed between
the client and a dedicated receiver app on the media device. The receiver
app communicates directly with an app-specific backend service to retrieve
and possibly control media playback.
2. Tab/desktop mirroring, where the media contents are streamed directly from
the browser to a generic streaming app on the media device and playback is
controlled by the browser.
This change adds support for device discovery and messaging (but not
mirroring) with functionality exposed via the new CefMediaRouter interface.
To test: Navigate to http://tests/media_router in cefclient and follow the
on-screen instructions.
This includes the following changes:
- Update usage of surface IDs to match the Aura implementation from the
RWHVAura/Window classes.
- Batch CefBrowserHost::WasResized calls to avoid excessive/unnecessary calls
to SynchronizeVisualProperties.
- Cache the results of CefRenderHandler::GetViewRect after resize and make
RWHVOSR::GetViewBounds the source of truth for all size calculations.
- Fix bounds calculations in CefVideoConsumerOSR with GPU enabled.
Known issues:
- The size passed to OnPaint may be off by 1 pixel in cases where the device
scale factor is not 1 and does not divide evenly into the pixel size. This is
due to the inexact conversion from integer pixel size to integer logical size
for GetViewRect.
The PDF loading documentation in extension_system.cc has be updated to
describe the new code paths.
To support delivery of input events to the mime handler renderer process it is
now necessary to route events via the correct RWHV interface. For Aura-based
platforms (Windows/Linux) this means RWHVAura::On*Event and for macOS this
means RWHVMac::RouteOrProcess*Event. Since Aura uses UI event types these have
become the source of truth on Aura-based platforms with conversion to Web event
types when needed (primarily for OSR).
This change also adds a timeout for CefProcessHostMsg_GetNewBrowserInfo to
avoid a hung renderer process if the guest WebContents route is not
registered via CefMimeHandlerViewGuestDelegate::OnGuestDetached as expected
prior to CefBrowserInfoManager::OnGetNewBrowserInfo being called. This
timeout can be disabled for testing purposes by passing the
`--disable-new-browser-info-timeout` command-line flag.
The `--disable-features=MimeHandlerViewInCrossProcessFrame` command-line
flag can be used for a limited time to restore the previous implementation
based on BrowserPlugin. That implementation will be deleted starting with
the 3897 branch update.
Known issues:
- ExecuteJavaScript calls on the frame hosting the PDF extension will not
be routed to the mime handler renderer process.
- The PDF extension will not load successfully if blocked by
ChromePluginPlaceholder and then manually continued via the "Run this
plugin" context menu option (see https://crbug.com/533069#c41).
These tests expect the window's client area size to be (kWSize, kWSize). Use
::AdjustWindowRect to offset TestWindowDelegate's preferred size so that the
client area size is correct after the OS internally applies frame insets during
::CreateWindow.
To test: Run `ceftests.exe --gtest_filter=ViewsWindowTest.Window*`.
All tests should pass.
Tests for incomplete request behavior use a timeout to trigger CloseBrowser
and terminate the test case. Recent architectural changes in Chromium have
likely increased the minimum delay required to spin up a working browser
instance and initiate the request. Consequently we need to wait longer before
closing the browser.
To test:
Run `ceftests --gtest_filter=URLRequestTest.*Incomplete* --gtest_repeat=5`.
All test runs should succeed.
This restores the default site isolation mode for Chromium on desktop
platforms. Unit tests have been updated to reflect the new behavior
expectations.
Known behavior changes in CEF are as follows:
- A spare renderer process may be created on initial browser creation or cross-
origin navigation. This spare process may be used with a future cross-origin
navigation or discarded on application shutdown. As a result
CefRenderProcessHandler::OnRenderThreadCreated, which is called shortly after
renderer process creation, can no longer be used to reliably transfer state
for the currently in-progress navigation. Unit tests have been updated to use
the CreateBrowser/OnBeforePopup |extra_info| value for transferring test state
to CefRenderProcessHandler::OnBrowserCreated which will be called in the
correct/expected renderer process.
- Cross-origin navigations will again receive a new renderer process, as
expected. This behavior had briefly regressed in M78 due to the
ProcessSharingWithDefaultSiteInstances feature becoming enabled by default.
- Cross-origin navigations initiated by calling LoadURL in the renderer process
will now crash that process with "bad IPC message" reason
INVALID_INITIATOR_ORIGIN (213). This is a security feature implemented in
Chromium.
- A DevTools browser created using CefBrowserHost::ShowDevTools will receive
the same CefRenderProcessHandler::OnBrowserCreated |extra_info| value that was
set via CreateBrowser/OnBeforePopup for the parent browser.
When NetworkService is enabled requests created using CefFrame::CreateURLRequest
will call CefRequestHandler::GetAuthCredentials for the associated browser after
calling CefURLRequestClient::GetAuthCredentials if that call returns false.
For 303 redirects all request methods except HEAD are converted to GET as per
the latest http draft. For historical reasons the draft also allows POST
requests to be converted to GETs when following 301/302 redirects. Most major
browsers do this and so shall we. When a request is converted to GET any POST
data should also be removed.
Use 307 redirects instead if you want the request to be repeated using the same
method and POST data.
Initialization of request objects requires asynchronous hops between the UI and
IO threads. In some cases the browser may be destroyed, the mojo connection may
be aborted, or the ProxyURLLoaderFactory object may be deleted while
initialization is still in progress. This change fixes crashes and adds unit
tests that try to reproduce these conditions.
To test: Run `ceftests --gtest_repeat=50
--gtest_filter=ResourceRequestHandlerTest.Basic*Abort*`
The behavior has changed as follows with NetworkService enabled:
- All pending and in-progress requests will now be aborted when the CEF context
or associated browser is destroyed. The OnResourceLoadComplete callback will
now also be called in this case for in-progress requests that have a handler.
- The CefResourceHandler::Cancel method will now always be called when resource
handling is complete, irrespective of whether handling completed successfully.
- Request callbacks that arrive after the OnBeforeClose callback for the
associated browser (which may happen for in-progress requests that are aborted
on browser destruction) will now always have a non-nullptr CefBrowser
parameter.
- Allow empty parameters to CefRequest and CefResponse methods where it makes
sense (e.g. resetting default response state, or clearing a referrer value).
- Fixed a reference loop that was keeping CefResourceHandler objects from being
destroyed if they were holding a callback reference (from ProcessRequest,
ReadResponse, etc.) during CEF context or associated browser destruction.
- Fixed an issue where the main frame was not detached on browser destruction
which could cause a crash due to RFH use-after-free (see issue #2498).
To test: All unit tests pass as expected.
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.
Cristian Amarie
Marshall Greenblatt
Vladislav
Andy Tzeng
Alexander Guettler
Daniel Nitsche
Mike Wiedenbauer
Iain Apreotesei@Arm
Petra Öhlin
Cristian Amarie