CefWindowImpl::CanHandleAccelerators was returning false for
accelerators triggered in the overlay BrowserView due to
IsWindowKey (called from NativeWidgetMac::IsActive) returning
false. View::CanHandleAccelerators, on the other hand, only
checks IsActive for Aura (non-MacOS) windows. We therefore
delegate to the View implementation for consistent handling.
These linker errors impact CEF builds but not Chromium builds due
to differences in application structure, and are becoming more
common with ongoing Chromium code refactoring.
When running via ASAN it may be necessary to set
`ASAN_OPTIONS=detect_odr_violation=0` to work around
https://github.com/google/sanitizers/issues/1017
When running with the overlay Browser enabled (`--show-overlay-browser`),
pressing Alt+O will move the overlay Browser to a new top-level Window.
Pressing Alt+O again or closing the new Window via the close button will
return the Browser to the overlay. Closing the Browser via `window.close()`
(in the new Window or overlay) will dismiss the overlay completely as
required to maintain consistent internal state. Detection of this state is
supported by the new CefBrowserHost::IsReadyToBeClosed method.
Draggable regions in the main Browser are updated to account for the
presence or absence of the overlay Browser. Support for draggable regions
in the overlay Browser in not implemented in cefclient.
Behavior with multiple overlays, `window.close()` and draggable regions
can be tested by adding `--hide-frame --hide-controls`.
TryCloseBrowser should potentially trigger JavaScript unload handlers
and return false. Add CefBrowserHost::IsReadyToBeClosed for detecting
mandatory close state. Enable, for Chrome style browsers, LifeSpanTest
that don't require DoClose(). Update related documentation.
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.
- 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.
Marshall Greenblatt
Nik Pavlov
Michael Bragg
Hunter Laux
Mike Bragg
Jacobo Aragunde Pérez