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.
- Add `declare_[cc|objc]_library` macros to configure common `copts`
and `local_defines` (where supported) on `[cc|objc]_library`
targets. This limits the scope of defines to the specific target
without inheritance by dependent targets.
- `objc_library` does not currently support `local_defines` so we
use `copts` instead of MacOS.
- Use `**kwargs` to pass all other arguments to the actual cc
target declaration.
- 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.