Avoid a circular ownership dependency between CefBrowserViewImpl and
CefBrowserPlatformDelegate[Chrome]Views (owned by CefBrowserHostBase).
Trigger CefBrowserHostBase destruction when the last CefBrowserViewImpl
reference is released.
This fixes a number of shutdown crashes related to overlay CefBrowsers
still existing at CefShutdown.
Adds new `--show-overlay-browser` command-line flag that creates an
overlay containing an Alloy-style BrowserView. The main BrowserView
may be Chrome- (default) or Alloy-style (add `--use-alloy-style`).
This overlay will only be added to standalone (non-popup) windows.
Popups triggered via the overlay will receive standard Alloy-style
handling in cefclient (e.g. Views-hosted window). Add
`--use-default-popup` for default popup handling.
ChromeCommandDispatcherDelegate forwards accelerator events to
the FocusManager through NativeWidgetMacNSWindowHost::
HandleAccelerator. Always initialize it so that accelerators also
work in a CefWindow without a BrowserView.
Some downloaded file types [1] default to opening in a Browser. Open
requests for these file types originating from the Download bubble UI
should route to the source Browser (call OnOpenURLFromTab). If
OnOpenURLFromTab is unhandled proceed with the default Chrome behavior
of opening the URL in a new default Browser.
[1] PDF, html, etc. For the complete list of file types see
ChromeDownloadManagerDelegate::IsOpenInBrowserPreferredForFile.
When the V8 sandbox is enabled, ArrayBuffer backing stores must be
allocated inside the sandbox address space. This change introduces a new
CefV8Value::CreateArrayBufferWithCopy method that copies the memory
contents into the sandbox address space.
Enabling the V8 sandbox can have a performance impact, especially when
passing large ArrayBuffers from C++ code to the JS side. We have therefore
retained the old CefV8Value::CreateArrayBuffer method that references
external memory. However, this method can only be used if the V8 sandbox is
disabled at CEF/Chromium build time.
To disable the V8 sandbox add `v8_enable_sandbox=false` to
`GN_DEFINES` when building CEF/Chromium.
The InterceptedRequestHandlerWrapper object may be deleted (likely via
~InterceptedRequest) while the task to call
InterceptedRequestHandlerWrapper:ContinueCreateURLLoaderNetworkObserver
is still pending. That binding holds a
WeakPtr<InterceptedRequestHandlerWrapper> (which is now nullptr)
resulting in the bound std::unique_ptr<PendingRequest> being deleted
while still holding a raw_ptr<network::ResourceRequest> to the
already-deleted object. This is always safe (raw_ptr will never be
dereferenced) because of the WeakPtr check.
Found using a CEF build with clang_use_chrome_plugins=true
and treat_warnings_as_errors=false.
This change rewrites remaining raw pointers reported by
chromium-rawptr checker and fixes a build error reported
by StackAllocatedChecker.
Fixes some issues introduced by 8e79307a62 (see #3314) and
6354d8daf1 (see #3239).
To test:
- Run `cefclient --url=chrome://net-export`
- Click the "Start Logging to Disk" button
- Exit cefclient; get no debug assertions
In this case |render_frame_| is not bound, |render_frame_host_| is
non-nullptr and |render_frame_host| equals |render_frame_host_| in
CefFrameHostImpl::MaybeReAttach when called from
CefBrowserInfo::FrameHostStateChanged.
The menu may not be running in the following cases:
- If the menu is empty (e.g. cleared in OnBeforeContextMenu).
- If the menu is disabled (see e.g. RenderViewContextMenuViews::Show).
- When the run call blocks until the menu is dismissed (macOS behavior).
We explicitly clean up in these cases instead of waiting for OnMenuClosed
which will otherwise never be called for the first 2 cases.
Menu run status is exposed via new ContextMenuDelegate and
RenderViewContextMenuBase methods.
The WinSboxNoFakeGdiInit feature requires delayload of all DLLs that
might load user32.dll in the renderer process. It's enabled as a field
trial for all non-Official builds, but caused problems with Debug
component builds using VS 17.5.0 due to MSVCP140D.dll depending on
OLE32.DLL (which depends on user32.dll). The dependency on OLE32.DLL
is removed with VS 17.9.2 so the feature can now be enabled.
See https://crbug.com/326277735#comment39 for background.
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`
The WinSboxNoFakeGdiInit feature requires delayload of all DLLs that
might load user32.dll in the renderer process. It's enabled as a field
trial for all non-Official builds, but appears to only work with
non-component Release builds. See https://crbug.com/326277735
Marshall Greenblatt
Nik Pavlov
Jacobo Aragunde Pérez
JC Yang
Loic Frasse-Mathon
Pedro de Carvalho Gomes
Marshall Greenblatt
Yuta Sekiguchi
pkv