This is no longer required now that we have implicit exclusion
of certain frame types including guest view frames.
Rename GuestView to ExcludedView in the renderer process.
Split the Alloy runtime into bootstrap and style components. Support
creation of Alloy style browsers and windows with the Chrome runtime.
Chrome runtime (`--enable-chrome-runtime`) + Alloy style
(`--use-alloy-style`) supports Views (`--use-views`), native parent
(`--use-native`) and windowless rendering
(`--off-screen-rendering-enabled`).
Print preview is supported in all cases except with windowless rendering
on all platforms and native parent on MacOS. It is disabled by default
with Alloy style for legacy compatibility. Where supported it can be
enabled or disabled globally using `--[enable|disable]-print-preview` or
configured on a per-RequestContext basis using the
`printing.print_preview_disabled` preference. It also behaves as
expected when triggered via the PDF viewer print button.
Chrome runtime + Alloy style behavior differs from Alloy runtime in the
following significant ways:
- Supports Chrome error pages by default.
- DevTools popups are Chrome style only (cannot be windowless).
- The Alloy extension API will not supported.
Chrome runtime + Alloy style passes all expected Alloy ceftests except
the following:
- `DisplayTest.AutoResize` (Alloy extension API not supported)
- `DownloadTest.*` (Download API not yet supported)
- `ExtensionTest.*` (Alloy extension API not supported)
This change also adds Chrome runtime support for
CefContextMenuHandler::RunContextMenu (see #3293).
This change also explicitly blocks (and doesn't retry) FrameAttached
requests from PDF viewer and print preview excluded frames (see #3664).
Known issues specific to Chrome runtime + Alloy style:
- DevTools popup with windowless rendering doesn't load successfully.
Use windowed rendering or remote debugging as a workaround.
- Chrome style Window with Alloy style BrowserView (`--use-alloy-style
--use-chrome-style-window`) does not show Chrome theme changes.
To test:
- Run `ceftests --enable-chrome-runtime --use-alloy-style
[--use-chrome-style-window] [--use-views|--use-native]
--gtest_filter=...`
- Run `cefclient --enable-chrome-runtime --use-alloy-style
[--use-chrome-style-window]
[--use-views|--use-native|--off-screen-rendering-enabled]`
- Run `cefsimple --enable-chrome-runtime --use-alloy-style [--use-views]`
Frame identifiers have changed from int64_t to string type. This is due
to https://crbug.com/1502660 which removes access to frame routing IDs
in the renderer process. New cross-process frame identifiers are 160-bit
values (32-bit child process ID + 128-bit local frame token) and most
easily represented as strings. All other frame-related expectations and
behaviors remain the same.
- chrome: Disable upgrade/downgrade behavior (see #3608)
- chrome: Disable process singleton behavior (see #3609)
- chrome: Disable config as default system browser (see #3613)
Write access to the shared memory region is required because JavaScript lacks
the capability to create read-only ArrayBuffers. When a user attempts to modify
an ArrayBuffer that utilizes a ReadOnlySharedMemoryRegion as its BackingStore
it triggers an access violation.
Note that this pull request may be reverted in the future if JavaScript adds
read-only ArrayBuffer support.
The CefFrame::CreateURLRequest method is no longer supported in the renderer
process. Usage of this method was already limited to same-origin requests due
to renderer process CORS restrictions, and the underlying Blink API has now
been removed in https://crbug.com/1413912 (M112+).
Existing alternatives include CefURLRequest usage in the browser process, or
JavaScript XMLHttpRequest/fetch API usage in the renderer process.
Send a FrameDetached message from CefFrameHostImpl::Detach before closing
the RenderFrame connection to avoid an immediate reconnect attempt by the
renderer.
When BFCache is disabled the intentionally detached frame will never be
reconnected. When BFCache is enabled the intentionally detached frame will
be reconnected via CefFrameImpl::OnWasShown if/when it exits the cache.
Run with "--vmodule=frame_*=1 --enable-logging=stderr --no-sandbox" on the
command-line to see these log messages from both the browser and renderer
processes.
CefSharedProcessMessageBuilder supports creation of a CefProcessMessage
backed by a CefSharedMemoryRegion.
Performance tests comparing the existing ArgumentList approach and the new
SharedMemoryRegion approach have been added to cefclient at
http://tests/ipc_performance.
CefMessageRouter has been updated to use SharedMemoryRegion as transport
for larger message payloads. The threshold is configurable via
|CefMessageRouterConfig.message_size_threshold|.
To test:
run `ceftests --gtest_filter=SendSharedProcessMessageTest.*:SharedProcessMessageTest.*:MessageRouterTest.Threshold*`
When bfcache is disabled use the RenderFrameObserver::DidFinishLoad notification
instead of the DidStopLoading notification that originates from the browser
process. During fast navigation the DidStopLoading notification may arrive in
the renderer after a new navigation has commenced and cause the wrong regions to
be reported.
- Windows: SDK version 10.0.20348.0 is now required.
- MacOS: SDK version 12.3 (Xcode 13.3) is now required.
- Legacy swiftshader binaries (`swiftshader/*` on Win/Linux and
`libswiftshader_*.dylib` on MacOS) have been removed (see issue #3176).
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.
Marshall Greenblatt
Nik Pavlov
David Cernoch
VodBox
Dmitry Azaraev
maikesiwu