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.
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]`
- 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.
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.
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.
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 adds new CefCommandHandler callbacks for optionally hiding
specific Chrome toolbar icons, buttons and app menu items.
To test: Run `cefclient --enable-chrome-runtime --filter-chrome-commands`.
Most icons, buttons and app/context menu items will be hidden.
Frameless windows now display as expected. Default traffic light buttons can
optionally be shown at configurable vertical position. Layout respects text
direction.
Custom global and request context preferences can now be registered via
CefBrowserProcessHandler::OnRegisterCustomPreferences. CefRequestContext
now extends CefPreferenceManager and global preferences can be accessed
via CefPreferenceManager::GetGlobalPreferenceManager.
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*`
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).
This change adds a `--use-default-popup` command-line option to cefclient. When
specified, popup windows will be created with default styling (e.g. without an
application-provided native parent window).
This change also adds some reasonable default window bounds in cases where they
are not specified by the client.
This change adds Chrome runtime support on Windows and Linux for creating a
browser parented to a native window supplied by the client application.
Expected API usage and window behavior is similar to what already exists with
the Alloy runtime. The parent window handle should be specified by using
CefWindowInfo::SetAsChild in combination with the CefBrowserHost::CreateBrowser
and CefLifeSpanHandler::OnBeforePopup callbacks.
The previously existing behavior of creating a fully-featured Chrome browser
window when empty CefWindowInfo is used with CreateBrowser remains unchanged
and Views is still the preferred API for creating top-level Chrome windows
with custom styling (e.g. title bar only, frameless, etc).
The cefclient Popup Window test with a native parent window continues to crash
on Linux with both the Alloy and Chrome runtimes (see issue #3165).
Also adds Chrome runtime support for CefDisplayHandler::OnCursorChange.
To test:
- Run `cefclient --enable-chrome-runtime [--use-views]` for the default (and
previously existing) Views-based behavior.
- Run `cefclient --enable-chrome-runtime --use-native` for the new native
parent window behavior.
- Run `cefclient --enable-chrome-runtime --use-native --no-activate` and the
window will not be activated (take input focus) on launch (Windows only).
- Run `cefclient --enable-chrome-runtime [--use-views|--use-native]
--mouse-cursor-change-disabled` and the mouse cursor will not change on
mouseover of DOM elements.
This change adds `CefBrowserSettings.chrome_status_bubble` for controlling
whether the Chrome status bubble will be used.
Testable in cefclient by passing the `--hide-chrome-status-bubble`
command-line flag.
To test:
Run `cefclient.exe --use-views --hide-frame --hide-controls`
Add `--enable-chrome-runtime` for the same behavior using the Chrome location
bar instead of a text field.
Widevine CDM binaries will be downloaded on supported platforms shortly after
application startup. Widevine support will then become available within a few
seconds after successful installation on Windows or after the next application
restart on other platforms. The CDM files will be downloaded to a "WidevineCdm"
directory inside the `CefSettings.user_data_path` directory.
Pass the `--disable-component-update` command-line flag to disable Widevine
download and installation. Pass the `--component-updater=fast-update` command-
line flag to force Widevine download immediately after application startup.
See the related issue for additional usage details.
- Convert scoped_ptr to std::unique_ptr from <memory>
- Convert arraysize to base::size from include/base/cef_cxx17_backports.h
- Convert NULL to nullptr
- Include include/base/cef_callback.h instead of include/base/cef_bind.h
- Implicit conversion of CefRefPtr<T> or scoped_refptr<T> to T* is gone;
use .get() instead
See the issue for additional details.
The Chrome runtime requires that cookieable scheme information be available
at Profile initialization time because it also triggers NetworkContext creation
at the same time. To make this possible, and to avoid various race conditions
when setting state, the cookieable scheme configuration has been added as
|cookieable_schemes_list| and |cookieable_schemes_exclude_defaults| in
CefSettings and CefBrowserContextSettings. The CefCookieManager::
SetSupportedSchemes and CefBrowserProcessHandler::GetCookieableSchemes methods
are no longer required and have been removed.
This change also modifies chrome to delay OffTheRecordProfileImpl initialization
so that |ChromeBrowserContext::profile_| can be set before
ChromeContentBrowserClientCef::ConfigureNetworkContextParams calls
CefBrowserContext::FromBrowserContext to retrieve the ChromeBrowserContext
and associated cookieable scheme information. Otherwise, the
ChromeBrowserContext will not be matched and the NetworkContext will not be
configured correctly.
The CookieTest suite now passes with the Chrome runtime enabled.
GTK3 is required by the Chrome runtime. The cefclient off-screen rendering
example no longer works with Ubuntu 16.04. With end-of-life in April 2021
we are dropping support for 16.04 in the near future in any case.
Marshall Greenblatt
Nik Pavlov
JohnKarel