cef/libcef/browser/alloy/alloy_browser_main.cc

425 lines
15 KiB
C++
Raw Normal View History

// Copyright (c) 2012 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#include "cef/libcef/browser/alloy/alloy_browser_main.h"
#include <stdint.h>
#include <memory>
#include <string>
#include "base/feature_list.h"
#include "base/functional/bind.h"
#include "base/strings/string_number_conversions.h"
#include "base/task/thread_pool.h"
#include "cef/libcef/browser/alloy/devtools/devtools_manager_delegate.h"
#include "cef/libcef/browser/alloy/dialogs/alloy_constrained_window_views_client.h"
#include "cef/libcef/browser/browser_context.h"
#include "cef/libcef/browser/browser_context_keyed_service_factories.h"
#include "cef/libcef/browser/context.h"
#include "cef/libcef/browser/extensions/extension_system_factory.h"
#include "cef/libcef/browser/file_dialog_runner.h"
#include "cef/libcef/browser/net/chrome_scheme_handler.h"
#include "cef/libcef/browser/permission_prompt.h"
#include "cef/libcef/browser/thread_util.h"
#include "cef/libcef/common/app_manager.h"
#include "cef/libcef/common/command_line_impl.h"
#include "cef/libcef/common/extensions/extensions_util.h"
#include "cef/libcef/common/net/net_resource_provider.h"
#include "chrome/browser/browser_process.h"
#include "chrome/browser/chrome_process_singleton.h"
#include "chrome/browser/media/router/chrome_media_router_factory.h"
#include "chrome/browser/net/system_network_context_manager.h"
#include "chrome/browser/ui/color/chrome_color_mixers.h"
#include "chrome/browser/ui/javascript_dialogs/chrome_javascript_app_modal_dialog_view_factory.h"
#include "chrome/browser/ui/ui_features.h"
#include "chrome/common/chrome_paths.h"
#include "chrome/common/chrome_switches.h"
#include "components/color/color_mixers.h"
#include "components/constrained_window/constrained_window_views.h"
#include "content/public/browser/gpu_data_manager.h"
#include "content/public/browser/network_service_instance.h"
#include "content/public/common/result_codes.h"
#include "extensions/browser/extensions_browser_client.h"
#include "extensions/common/constants.h"
#include "net/base/net_module.h"
#include "third_party/widevine/cdm/buildflags.h"
#include "ui/base/resource/resource_bundle.h"
#include "ui/color/color_provider_manager.h"
#include "ui/native_theme/native_theme.h"
#if BUILDFLAG(IS_LINUX)
#include "ui/base/ozone_buildflags.h"
#if defined(USE_AURA) && BUILDFLAG(IS_OZONE_X11)
#include "ui/events/devices/x11/touch_factory_x11.h"
#endif
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
#if defined(USE_DBUS)
#include "chrome/browser/ui/views/dark_mode_manager_linux.h"
#endif
#endif
#if defined(USE_AURA)
#include "ui/aura/env.h"
#include "ui/views/widget/desktop_aura/desktop_screen.h"
#include "ui/wm/core/wm_state.h"
#if BUILDFLAG(IS_WIN)
#include "base/enterprise_util.h"
#include "base/files/file_util.h"
#include "chrome/browser/chrome_browser_main_win.h"
#include "chrome/browser/win/parental_controls.h"
#endif
#endif // defined(USE_AURA)
#if BUILDFLAG(IS_MAC)
#include "chrome/browser/ui/views/chrome_layout_provider.h"
#include "chrome/browser/ui/views/chrome_views_delegate.h"
#else
#include "ui/views/test/desktop_test_views_delegate.h"
#endif
#if defined(USE_AURA) && BUILDFLAG(IS_LINUX)
#include "ui/base/ime/init/input_method_initializer.h"
#endif
#if BUILDFLAG(IS_WIN) || BUILDFLAG(IS_LINUX)
#include "components/os_crypt/sync/os_crypt.h"
#endif
#if BUILDFLAG(IS_LINUX)
#include "base/path_service.h"
#include "cef/libcef/browser/printing/print_dialog_linux.h"
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
#include "chrome/browser/themes/theme_service_aura_linux.h"
#include "chrome/browser/ui/views/theme_profile_key.h"
#include "chrome/grit/branded_strings.h"
#include "components/os_crypt/sync/key_storage_config_linux.h"
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
#include "ui/base/cursor/cursor_factory.h"
#include "ui/base/ime/input_method.h"
#include "ui/base/l10n/l10n_util.h"
#include "ui/linux/linux_ui.h"
#include "ui/linux/linux_ui_delegate.h"
#include "ui/linux/linux_ui_factory.h"
#include "ui/linux/linux_ui_getter.h"
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
#include "ui/ozone/public/ozone_platform.h"
#endif // BUILDFLAG(IS_LINUX)
#if BUILDFLAG(ENABLE_MEDIA_FOUNDATION_WIDEVINE_CDM)
#include "chrome/browser/component_updater/media_foundation_widevine_cdm_component_installer.h"
#endif
#if BUILDFLAG(ENABLE_WIDEVINE_CDM_COMPONENT)
#include "chrome/browser/component_updater/widevine_cdm_component_installer.h"
#endif
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
namespace {
#if BUILDFLAG(IS_LINUX)
class LinuxUiGetterImpl : public ui::LinuxUiGetter {
public:
LinuxUiGetterImpl() = default;
~LinuxUiGetterImpl() override = default;
ui::LinuxUiTheme* GetForWindow(aura::Window* window) override {
return window ? GetForProfile(GetThemeProfileForWindow(window)) : nullptr;
}
ui::LinuxUiTheme* GetForProfile(Profile* profile) override {
return ui::GetLinuxUiTheme(
ThemeServiceAuraLinux::GetSystemThemeForProfile(profile));
}
};
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
#endif // BUILDFLAG(IS_LINUX)
void ProcessSingletonNotificationCallbackImpl(
base::CommandLine command_line,
const base::FilePath& current_directory) {
// Drop the request if the browser process is already shutting down.
if (!CONTEXT_STATE_VALID()) {
return;
}
bool handled = false;
if (auto app = CefAppManager::Get()->GetApplication()) {
if (auto handler = app->GetBrowserProcessHandler()) {
CefRefPtr<CefCommandLineImpl> commandLinePtr(
new CefCommandLineImpl(command_line));
handled = handler->OnAlreadyRunningAppRelaunch(commandLinePtr.get(),
current_directory.value());
std::ignore = commandLinePtr->Detach(nullptr);
}
}
if (!handled) {
LOG(WARNING) << "Unhandled app relaunch; implement "
"CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.";
}
}
// Based on ChromeBrowserMainParts::ProcessSingletonNotificationCallback.
bool ProcessSingletonNotificationCallback(
base::CommandLine command_line,
const base::FilePath& current_directory) {
// Drop the request if the browser process is already shutting down.
// Note that we're going to post an async task below. Even if the browser
// process isn't shutting down right now, it could be by the time the task
// starts running. So, an additional check needs to happen when it starts.
// But regardless of any future check, there is no reason to post the task
// now if we know we're already shutting down.
if (!CONTEXT_STATE_VALID()) {
return false;
}
// In order to handle this request on Windows, there is platform specific
// code in browser_finder.cc that requires making outbound COM calls to
// cross-apartment shell objects (via IVirtualDesktopManager). That is not
// allowed within a SendMessage handler, which this function is a part of.
// So, we post a task to asynchronously finish the command line processing.
return base::SingleThreadTaskRunner::GetCurrentDefault()->PostTask(
FROM_HERE, base::BindOnce(&ProcessSingletonNotificationCallbackImpl,
std::move(command_line), current_directory));
}
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
} // namespace
AlloyBrowserMainParts::AlloyBrowserMainParts() = default;
AlloyBrowserMainParts::~AlloyBrowserMainParts() {
constrained_window::SetConstrainedWindowViewsClient(nullptr);
}
void AlloyBrowserMainParts::ToolkitInitialized() {
chrome: Add support for Alloy style browsers and windows (see #3681) 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]`
2024-04-17 18:01:26 +02:00
SetConstrainedWindowViewsClient(
CreateAlloyConstrainedWindowViewsClient(nullptr));
#if defined(USE_AURA)
CHECK(aura::Env::GetInstance());
wm_state_ = std::make_unique<wm::WMState>();
#endif // defined(USE_AURA)
#if BUILDFLAG(IS_MAC)
views_delegate_ = std::make_unique<ChromeViewsDelegate>();
layout_provider_ = ChromeLayoutProvider::CreateLayoutProvider();
#else
views_delegate_ = std::make_unique<views::DesktopTestViewsDelegate>();
#endif
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
#if BUILDFLAG(IS_LINUX)
// Based on chrome_browser_main_extra_parts_views_linux.cc
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
// |linux_ui| will be nullptr with multi-threaded-message-loop. See
// CefUiThread::InitializeBrowserRunner.
if (auto linux_ui = ui::GetDefaultLinuxUi()) {
linux_ui_getter_ = std::make_unique<LinuxUiGetterImpl>();
ui::LinuxUi::SetInstance(linux_ui);
// Cursor theme changes are tracked by LinuxUI (via a CursorThemeManager
// implementation). Start observing them once it's initialized.
ui::CursorFactory::GetInstance()->ObserveThemeChanges();
}
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
#if defined(USE_DBUS)
if (!ui::NativeTheme::IsForcedDarkMode() &&
!ui::NativeTheme::IsForcedLightMode()) {
dark_mode_manager_ = std::make_unique<ui::DarkModeManagerLinux>();
}
#endif
auto printing_delegate = new CefPrintingContextLinuxDelegate();
auto default_delegate =
ui::PrintingContextLinuxDelegate::SetInstance(printing_delegate);
printing_delegate->SetDefaultDelegate(default_delegate);
#endif // BUILDFLAG(IS_LINUX)
#if BUILDFLAG(IS_MAC)
2023-01-02 23:59:03 +01:00
if (base::FeatureList::IsEnabled(features::kViewsJSAppModalDialog)) {
InstallChromeJavaScriptAppModalDialogViewFactory();
2023-01-02 23:59:03 +01:00
} else {
InstallChromeJavaScriptAppModalDialogViewCocoaFactory();
2023-01-02 23:59:03 +01:00
}
#else
InstallChromeJavaScriptAppModalDialogViewFactory();
#endif
// On GTK that builds the native theme that, in turn, adds the GTK core color
// mixer; core mixers should all be added before we add chrome mixers.
ui::ColorProviderManager::Get().AppendColorProviderInitializer(
base::BindRepeating(color::AddComponentsColorMixers));
ui::ColorProviderManager::Get().AppendColorProviderInitializer(
base::BindRepeating(AddChromeColorMixers));
}
void AlloyBrowserMainParts::PreCreateMainMessageLoop() {
#if BUILDFLAG(IS_LINUX)
#if defined(USE_AURA) && BUILDFLAG(IS_OZONE_X11)
ui::TouchFactory::SetTouchDeviceListFromCommandLine();
#endif
#endif
#if BUILDFLAG(IS_WIN)
// Initialize the OSCrypt.
PrefService* local_state = g_browser_process->local_state();
DCHECK(local_state);
bool os_crypt_init = OSCrypt::Init(local_state);
DCHECK(os_crypt_init);
// installer_util references strings that are normally compiled into
// setup.exe. In Chrome, these strings are in the locale files.
ChromeBrowserMainPartsWin::SetupInstallerUtilStrings();
#endif // BUILDFLAG(IS_WIN)
media_router::ChromeMediaRouterFactory::DoPlatformInit();
}
void AlloyBrowserMainParts::PostCreateMainMessageLoop() {
#if BUILDFLAG(IS_LINUX)
const base::CommandLine* command_line =
base::CommandLine::ForCurrentProcess();
// Set up crypt config. This needs to be done before anything starts the
// network service, as the raw encryption key needs to be shared with the
// network service for encrypted cookie storage.
// Based on ChromeBrowserMainPartsLinux::PostCreateMainMessageLoop.
std::unique_ptr<os_crypt::Config> config =
std::make_unique<os_crypt::Config>();
// Forward to os_crypt the flag to use a specific password store.
config->store = command_line->GetSwitchValueASCII(switches::kPasswordStore);
// Forward the product name (defaults to "Chromium").
config->product_name = l10n_util::GetStringUTF8(IDS_PRODUCT_NAME);
// OSCrypt can be disabled in a special settings file.
config->should_use_preference =
command_line->HasSwitch(switches::kEnableEncryptionSelection);
base::PathService::Get(chrome::DIR_USER_DATA, &config->user_data_path);
DCHECK(!config->user_data_path.empty());
OSCrypt::SetConfig(std::move(config));
#endif // BUILDFLAG(IS_LINUX)
#if BUILDFLAG(IS_WIN)
base::SetExtraNoExecuteAllowedPath(chrome::DIR_USER_DATA);
#endif
}
int AlloyBrowserMainParts::PreCreateThreads() {
#if BUILDFLAG(IS_WIN)
PlatformInitialize();
#endif
net::NetModule::SetResourceProvider(&NetResourceProvider);
// Initialize these objects before IO access restrictions are applied and
// before the IO thread is started.
content::GpuDataManager::GetInstance();
SystemNetworkContextManager::CreateInstance(g_browser_process->local_state());
return 0;
}
void AlloyBrowserMainParts::PostCreateThreads() {
ChromeProcessSingleton::GetInstance()->StartWatching();
}
int AlloyBrowserMainParts::PreMainMessageLoopRun() {
#if defined(USE_AURA)
screen_ = views::CreateDesktopScreen();
#endif
#if BUILDFLAG(IS_MAC)
screen_ = std::make_unique<display::ScopedNativeScreen>();
#endif
if (extensions::ExtensionsEnabled()) {
// This should be set in ChromeBrowserProcessAlloy::Initialize.
DCHECK(extensions::ExtensionsBrowserClient::Get());
// Initialize extension global objects before creating the global
// BrowserContext.
extensions::CefExtensionSystemFactory::GetInstance();
}
// Register additional KeyedService factories here. See
// ChromeBrowserMainExtraPartsProfiles for details.
cef::EnsureBrowserContextKeyedServiceFactoriesBuilt();
background_task_runner_ = base::ThreadPool::CreateSingleThreadTaskRunner(
{base::TaskPriority::BEST_EFFORT,
base::TaskShutdownBehavior::BLOCK_SHUTDOWN, base::MayBlock()});
user_visible_task_runner_ = base::ThreadPool::CreateSingleThreadTaskRunner(
{base::TaskPriority::USER_VISIBLE,
base::TaskShutdownBehavior::BLOCK_SHUTDOWN, base::MayBlock()});
user_blocking_task_runner_ = base::ThreadPool::CreateSingleThreadTaskRunner(
{base::TaskPriority::USER_BLOCKING,
base::TaskShutdownBehavior::BLOCK_SHUTDOWN, base::MayBlock()});
Add support for complete isolation of storage and permissions (cache, cookies, localStorage, access grants, etc) on a per-request-context basis (issue #1044). - CefRequestContext instances can be configured using a new CefRequestContextSettings structure passed to CefRequestContext::CreateContext. - Scheme registration is now per-request-context using new CefRequestContext::RegisterSchemeHandlerFactory and ClearSchemeHandlerFactories methods. - Cookie managers are now per-request-context by default and can be retrieved using a new CefRequestContext::GetDefaultCookieManager method. - CefURLRequest::Create now accepts an optional CefRequestContext argument for associating a URL request with a context (browser process only). - The CefRequestContextHandler associated with a CefRequestContext will not be released until all objects related to that context have been destroyed. - When the cache path is empty an in-memory cache ("incognito mode") will be used for storage and no data will be persisted to disk. - Add CefSettings.user_data_path which specifies the location where user data such as spell checking dictionary files will be stored on disk. - Add asynchronous callbacks for all CefCookieManager methods. - Add PK_LOCAL_APP_DATA and PK_USER_DATA path keys for retrieving user directories via CefGetPath. - cefclient: Add "New Window" test that creates a new window unrelated to existing windows. When used in combination with `--request-context-per-browser` the new window will be given a new and isolated request context. git-svn-id: https://chromiumembedded.googlecode.com/svn/trunk@2040 5089003a-bbd8-11dd-ad1f-f1f9622dbc98
2015-03-02 21:25:14 +01:00
CefRequestContextSettings settings;
CefContext::Get()->PopulateGlobalRequestContextSettings(&settings);
Add support for complete isolation of storage and permissions (cache, cookies, localStorage, access grants, etc) on a per-request-context basis (issue #1044). - CefRequestContext instances can be configured using a new CefRequestContextSettings structure passed to CefRequestContext::CreateContext. - Scheme registration is now per-request-context using new CefRequestContext::RegisterSchemeHandlerFactory and ClearSchemeHandlerFactories methods. - Cookie managers are now per-request-context by default and can be retrieved using a new CefRequestContext::GetDefaultCookieManager method. - CefURLRequest::Create now accepts an optional CefRequestContext argument for associating a URL request with a context (browser process only). - The CefRequestContextHandler associated with a CefRequestContext will not be released until all objects related to that context have been destroyed. - When the cache path is empty an in-memory cache ("incognito mode") will be used for storage and no data will be persisted to disk. - Add CefSettings.user_data_path which specifies the location where user data such as spell checking dictionary files will be stored on disk. - Add asynchronous callbacks for all CefCookieManager methods. - Add PK_LOCAL_APP_DATA and PK_USER_DATA path keys for retrieving user directories via CefGetPath. - cefclient: Add "New Window" test that creates a new window unrelated to existing windows. When used in combination with `--request-context-per-browser` the new window will be given a new and isolated request context. git-svn-id: https://chromiumembedded.googlecode.com/svn/trunk@2040 5089003a-bbd8-11dd-ad1f-f1f9622dbc98
2015-03-02 21:25:14 +01:00
// Create the global RequestContext.
global_request_context_ =
CefRequestContextImpl::CreateGlobalRequestContext(settings);
auto browser_context =
global_request_context_->GetBrowserContext()->AsBrowserContext();
CefDevToolsManagerDelegate::StartHttpHandler(browser_context);
#if BUILDFLAG(IS_WIN)
// Windows parental controls calls can be slow, so we do an early init here
// that calculates this value off of the UI thread.
InitializeWinParentalControls();
// These methods may call LoadLibrary and could trigger
// AssertBlockingAllowed() failures if executed at a later time on the UI
// thread.
base::IsManagedDevice();
base::IsEnterpriseDevice();
#endif // BUILDFLAG(IS_WIN)
scheme::RegisterWebUIControllerFactory();
Use Chrome file dialogs on all platforms and runtimes (fixes issue #3314) 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).
2022-04-15 21:55:23 +02:00
file_dialog_runner::RegisterFactory();
permission_prompt::RegisterCreateCallback();
// Initialize theme configuration (high contrast, dark mode, etc).
ui::NativeTheme::GetInstanceForNativeUi();
#if BUILDFLAG(ENABLE_MEDIA_FOUNDATION_WIDEVINE_CDM) || \
BUILDFLAG(ENABLE_WIDEVINE_CDM_COMPONENT)
const base::CommandLine* command_line =
base::CommandLine::ForCurrentProcess();
if (!command_line->HasSwitch(switches::kDisableComponentUpdate)) {
auto* const cus = g_browser_process->component_updater();
#if BUILDFLAG(ENABLE_MEDIA_FOUNDATION_WIDEVINE_CDM)
RegisterMediaFoundationWidevineCdmComponent(cus);
#endif
#if BUILDFLAG(ENABLE_WIDEVINE_CDM_COMPONENT)
RegisterWidevineCdmComponent(cus);
#endif
}
#endif
// Allow ProcessSingleton to process messages.
// This is done here instead of just relying on the main message loop's start
// to avoid rendezvous in RunLoops that may precede MainMessageLoopRun.
ChromeProcessSingleton::GetInstance()->Unlock(
base::BindRepeating(&ProcessSingletonNotificationCallback));
return content::RESULT_CODE_NORMAL_EXIT;
}
void AlloyBrowserMainParts::PostMainMessageLoopRun() {
// NOTE: Destroy objects in reverse order of creation.
CefDevToolsManagerDelegate::StopHttpHandler();
ChromeProcessSingleton::GetInstance()->Cleanup();
// There should be no additional references to the global CefRequestContext
// during shutdown. Did you forget to release a CefBrowser reference?
DCHECK(global_request_context_->HasOneRef());
global_request_context_ = nullptr;
}
void AlloyBrowserMainParts::PostDestroyThreads() {
views_delegate_.reset();
#if BUILDFLAG(IS_MAC)
layout_provider_.reset();
#endif
}