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*`
Popup windows will be created on the display that best matches the requested
coordinates. The requested size will apply to the content area (as required by
JS documentation) and window size will be reduced if necessary to fit within the
target display. The requested origin will apply to the window (including frame)
and will be modified if necessary so that the window is fully visible on the
target display.
This change does not implement popup positioning for cefclient which uses an
application-created parent window.
This change grants access to the getScreenDetails JS API without user prompt.
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).
This was causing early access to ResourceBundle on the main thread (via
webui::GetFontFamily) which resulted in crashes on Linux when running
with multi-threaded-message-loop.
All file dialogs irrespective of source, platform and runtime will now be
routed through CefFileDialogManager and trigger CefDialogHandler callbacks
(see issue #3293).
Adds Chrome runtime support for CefBrowserHost::RunFileDialog and
CefDialogHandler callbacks.
Adds Alloy runtime support for internal GTK file and print dialogs on Linux
subject to the following limitations:
1. Internal GTK implementation:
- Cannot be used with multi-threaded-message-loop because Chromium's
internal GTK implementation is not thread-safe (does not use GDK threads).
- Dialogs will not be modal to application windows when used with off-screen
rendering due to lack of access to the client's top-level GtkWindow.
2. Cefclient CefDialogHandler implementation:
- Cannot be used with Views because it requires a top-level GtkWindow.
Due to the above limitations no dialog implementation is currently provided for
Views + multi-threaded-message-loop on Linux. In cases where both
implementations are supported the cefclient version is now behind an optional
`--use-client-dialogs` command-line flag.
Expressly forbids multiple simultaneous file dialogs with the internal platform
implementation which uses modal dialogs. CefDialogHandler will still be notified
and can optionally handle each request without a modal dialog (see issue #3154).
Removes some RunFileDialog parameters that are not supported by the Chrome file
dialog implementation (selected_accept_filter parameter, cef_file_dialog_mode_t
overwrite/read-only flags).
Switch to using aura::CursorLoader which knows how to load system, non-system
and pak cursor resources.
On Windows, cursors will be loaded via LoadCursor first if available with a
fallback to pak file if necessary (like with component builds).
On Linux, all non-system cursor resources will be loaded from pak file. Cursors
may be loaded asynchronously resulting in the default (pointer) cursor being
returned on the first request.
Calling DetachToUserFree() on a CefString holding a reference should copy the
value instead of transferring ownership.
A new `StringTest.Ownership` test has been added for this behavior.
This change provides a generic solution for active (key) window tracking that
works with both Views-hosted and native windows on MacOS. With this new approach
we can now successfully route top menu actions to the currently active window.
Prior to this change CEF's Views API was using focus notifications as a proxy
for window activation notifications. That doesn't work on MacOS where NSWindow
activation (key status) is independent of NSView focus (first responder) status,
and changes in activation don't necessarily generate focus notifications (see
NativeWidgetMac::OnWindowKeyStatusChanged). To make this work reliably on all
platforms we now expose a CefWindowDelegate::OnWindowActivationChanged callback.
This change also fixes an uninitialized variable
(RootWindowMacImpl::with_extension_) that was causing flaky behavior in
RootWindowManager::OnRootWindowActivated.
To test:
1. Run `cefclient [--use-views]`
2. Select Popup Window from the Tests menu. Do not explicitly activate the popup
window (e.g. don't click on it).
3. Verify that further Tests menu actions go to the popup window.
4. Change activation to a first window by clicking on it. Verify that Test
menu actions go to that window.
5. Close the currently active window. Do not explicitly activate the remaining
window (e.g. don't click on it).
6. Verify that Test menu actions go to the only remaining window.
Popup windows will be created on the display that best matches the requested
coordinates. The requested size will apply to the content area (as required by
JS documentation) and window size will be reduced if necessary to fit within the
target display. The requested origin will apply to the window (including frame)
and will be modified if necessary so that the window is fully visible on the
target display.
Nik Pavlov
Marshall Greenblatt
Sergey Markelov
Jelle Bleyaert
JohnKarel
Joshua Marler
maikesiwu