File dialogs that specify mime type (e.g. "image/*") accept filters will pass
those values unchanged to the OnFileDialog |accept_filters| parameter. The
default dialog implementation will show those filters in addition to a combined
"Custom Files" filter. This is a change from preexisting Google Chrome
behavior where only the combined "Custom Files" filter is displayed, and
restores CEF behavior that existed prior to 2ea7459a89.
Document the fact that OnFileDialog may be called twice, once before MIME type
expansion and once afterwards.
Add new OnFileDialog |accept_extensions| and |accept_descriptions| parameters
for MIME type extensions and descriptions.
Details: This change adds a SelectFileDialog::FileTypeInfo::extension_mimetypes
member and improves the logic in FileSelectHelper::GetFileTypesFromAcceptType
and file_dialog_manager.cc SelectFileToFileChooserParams to support recall of
the source mime type when populating the FileChooserParams structure.
To test:
- Run `ceftests --gtest_filter=DialogTest.*`
- Run `cefclient --url=https://tests/dialogs`
Set enable_alloy_bootstrap=false to build with Alloy bootstrap code
removed. Extension API is documented as deprecated in comments but
not compiled out with this arg.
Adds support for the OnAcceleratedPaint callback. Verified to work
on macOS and Windows. Linux support is present but not implemented
for cefclient, so it is not verified to work.
To test:
Run `cefclient --off-screen-rendering-enabled --shared-texture-enabled`
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]`
Controls now respect OS and Chrome themes by default for both Alloy
and Chrome runtimes. Chrome themes (mode and colors) can be configured
using the new CefRequestContext::SetChromeColorScheme method. Individual
theme colors can be overridden using the new CefWindowDelegate::
OnThemeColorsChanged and CefWindow::SetThemeColor methods.
The `--force-light-mode` and `--force-dark-mode` command-line flags are
now respected on all platforms as an override for the OS theme.
The current Chrome theme, if any, will take precedence over the OS theme
when determining light/dark status. On Windows and MacOS the titlebar
color will also be updated to match the light/dark theme.
Testable as follows:
- Run: `cefclient --enable-chrome-runtime` OR
`cefclient --use-views --persist-user-preferences --cache-path=...`
- App launches with default OS light/dark theme colors.
- Change OS dark/light theme under system settings. Notice that theme
colors change as expected.
- Right click, select items from the new Theme sub-menu. Notice that
theme colors behave as expected.
- Exit and relaunch the app. Notice that the last-used theme colors are
applied on app restart.
- Add `--background-color=green` to above command-line.
- Perform the same actions as above. Notice that all controls start
and remain green throughout (except some icons with Chrome runtime).
- Add `--force-light-mode` or `--force-dark-mode` to above command-line.
- Perform the same actions as above. Notice that OS dark/light theme
changes are ignored, but Chrome theme changes work as expected.
The client can optionally wait or terminate the render process.
Expose process exit codes via OnRenderProcessTerminated and
CefGetExitCode (fixes#2126).
cefclient: Add a new https://tests/hang page for testing hang behavior.
cefclient: Move message and resource handling to a new BaseClientHandler
class to support loading of test pages in default Chrome UI windows.
Selecting a new user or incognito profile via Chrome UI may result in
the creation of a new Profile object. If that occurs, we should find
or create a matching CefBrowserContext and CefRequestContext instead
of reusing an existing mismatched context (e.g. using the original
context for an incognito window would be a mismatch). If a new
CefRequestContext will be created the client can now implement
CefBrowserProcessHandler::GetDefaultRequestContextHandler() to
provide the handler for that context.
To test with a new user profile:
1. Click "Profile" icon, select "Add". Now you have 2+ profiles.
2. Click "Profile" icon, select the other user name to create a new
window using the other user profile.
3. The new window should launch successfully.
To test with a new incognito profile:
1. Select "New Incognito window" from the 3-dot menu.
2. The new window should launch successfully.
To test DevTools window creation for the new profile:
1. Right-click in the new window, select Inspect.
2. The DevTools window should launch successfully.
- Adds `--initial-show-state=hidden` support for cefclient and cefsimple
where the window launches as initially hidden (no dock thumbnail).
- Adds `--hide-window-on-close` support for cefclient where clicking the
red traffic light button hides the window instead of closing it.
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.
Adds a new CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch
callback for when an already running app is relaunched with the
same CefSettings.root_cache_path.
Client apps should check the CefInitialize() return value for early
exit of the relaunch source process.
- chrome: Disable upgrade/downgrade behavior (see #3608)
- chrome: Disable process singleton behavior (see #3609)
- chrome: Disable config as default system browser (see #3613)
Add new CefBrowserHost::[Can]ExecuteChromeCommand methods for executing
arbitrary Chrome commands.
Add support for existing CefBrowserHost::ShowDevTools, CloseDevTools and
HasDevTools methods.
DevTools windows now support the same Views callbacks as normal popup
windows with the new CefLifeSpanHandler::OnBeforeDevToolsPopup callback
as the DevTools-specific equivalent of OnBeforePopup.
Always create DevTools as an undocked window to support use of
ShowDevTools with default Chrome browser windows.
To test:
Run `ceftests --enable-chrome-runtime [--use-views]
--gtest_filter=V8Test.OnUncaughtExceptionDevTools`
OR:
1. Run `cefclient --enable-chrome-runtime [--use-native]`
2. Select "Show DevTools", "Close DevTools" or "Inspect" from the
right-click menu.
3. Notice that the DevTools window is Views-hosted (or native-hosted)
and works as expected.
Add --use-default-popup to get a default styled popup in step 3.
Disable Chrome policy management by default. Add CefSettings.chrome_policy_id
which, when configured, enables Chrome policy management. See
https://support.google.com/chrome/a/answer/9037717 for background.
To test:
- Start with a machine where Google Chrome is managed.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/`
There should be no configured policies.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/
--enable-chrome-policy`
Configured Platform properties should match Google Chrome.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/
--enable-chrome-policy --enable-chrome-browser-cloud-management`
Configured Platform and Cloud properties should match Google Chrome.
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.
Add a simpler CanZoom/Zoom API as an alternative to the more error-prone
SetZoomLevel/GetZoomLevel API. Both APIs are now implemented for both runtimes.
With the Chrome runtime a zoom notification bubble will be displayed unless
CefBrowserSettings.chrome_zoom_bubble is set to STATE_DISABLED.
To test:
- Run cefclient and select zoom entries from the Tests menu.
- chrome: Run cefclient with `--hide-chrome-bubbles` command-line flag to hide
the zoom notification bubble.
Use the same code path for all fullscreen transitions so that Chrome UI updates
correctly. All user-initiated fullscreen transitions now result in
CefWindowDelegate::OnWindowFullscreenTransition callbacks.
A modal dialog is a child CefWindow that implements some special behaviors
relative to a parent CefWindow. Like any CefWindow it can be framed with
titlebar or frameless, and optionally contain draggable regions (subject to
platform limitations described below). Modal dialogs are shown centered on
the parent window (inside a single display) and always stay on top of the
parent window in z-order. Sizing behavior and available window buttons are
controlled via the usual CefWindowDelegate callbacks. For example, the dialog
can have a preferred size with resize, minimize and maximize disabled (via
GetPreferredSize, CanResize, CanMinimize and CanMaximize respectively).
This change adds support for two modality modes. With window modality all
controls in the parent window are disabled. With browser modality only the
browser view in the parent window is disabled.
Both modality modes require that a valid parent window be returned via
GetParentWindow. For window modality return true from IsWindowModalDialog
and call CefWindow::Show. For browser modality return false from
IsWindowModalDialog (the default value) and call
CefWindow::ShowAsBrowserModalDialog with a reference to the parent window's
browser view.
Window modal dialog behavior depends on the platform. On Windows and
Linux these dialogs have a titlebar and can be moved independent of the
parent window. On macOS these dialogs do not have a titlebar, move with
the parent window, and do not support draggable regions (because they are
implemented using sheets). On Linux disabling the parent window controls
requires a window manager the supports _NET_WM_STATE_MODAL.
Browser modal dialog behavior is similar on all platforms. The dialog will
be automatically sized and positioned relative to the parent window's
browser view. Closing the parent window or navigating the parent browser
view will dismiss the dialog. The dialog can also be moved independent of
the parent window though it will be recentered when the parent window
itself is resized or redisplayed. On MacOS the dialog will move along with
the parent window while on Windows and Linux the parent window can be moved
independently.
To test: Use the Tests > Dialog Window menu option in cefclient with Views
enabled (`--use-views` or `--enable-chrome-runtime` command-line flag).
Browser modal dialog is the default behavior. For window modal dialog add
the `--use-window-modal-dialog` command-line flag.
This change replaces existing CefSettings.user_data_path usage with
CefSettings.root_cache_path for better alignment with the Chrome runtime.
All files should now be written inside the root_cache_path directory.
This adds support for the three-finger-swipe navigation gesture with
Alloy/Views. The default implementation matches the Chrome runtime
and navigates the browser back/forward. We also add an Alloy/Views-
specific client callback in CefBrowserViewDelegate for optional
custom handling of the gesture event.
Marshall Greenblatt
reito
Nik Pavlov
Philipp Thiel
Cristian Amarie
Julien Bouix
Vladimir Kharitonov