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.
- Headers that are included by .rc files need to be supplied to
`declare_exe` via the `resources_deps` attribute (passed as the `deps
attribute to `compile_rc`). The headers must be part of a cc_library
target via either the `hdrs` or `srcs` attribute.
- File paths for CEF resources are prefixed with "external/<repo>"
when CEF is loaded as an external repo. Update `copy_filegroups` to
work with these paths.
Unqualified target labels don't resolve correctly when the
disribution is loaded as an external repo. Mapping, if necessary,
can be performed using the `repo_mapping` parameter to
http_archive() or local_repository().
Add support for building the CEF binary distribution using Bazel
and the default platform toolchain. Tested to work for Windows
x64, MacOS ARM64 and x64 (cross-compile from ARM64), and
Linux x64. Windows x86 (cross-compile from x64) is known to
be broken, see https://github.com/bazelbuild/bazel/issues/22164.
Includes minor changes to tests directory structure to meet
Bazel build requirements.
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.
JC Yang
Sergey Markelov
Loic Frasse-Mathon
Pedro de Carvalho Gomes
Nik Pavlov
Marshall Greenblatt
Marshall Greenblatt
Yuta Sekiguchi
Julian Waller