cef/libcef/browser/printing/print_dialog_linux.cc

346 lines
9.8 KiB
C++
Raw Permalink Normal View History

// Copyright (c) 2014 The Chromium Embedded Framework Authors.
// Portions 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/printing/print_dialog_linux.h"
#include <string>
#include <vector>
#include "base/files/file_util.h"
#include "base/functional/bind.h"
#include "base/lazy_instance.h"
#include "base/logging.h"
#include "base/strings/utf_string_conversions.h"
#include "base/values.h"
#include "cef/libcef/browser/browser_host_base.h"
#include "cef/libcef/browser/print_settings_impl.h"
#include "cef/libcef/browser/thread_util.h"
#include "cef/libcef/common/app_manager.h"
#include "cef/libcef/common/frame_util.h"
#include "content/public/browser/global_routing_id.h"
#include "printing/metafile.h"
#include "printing/mojom/print.mojom-shared.h"
#include "printing/print_job_constants.h"
#include "printing/print_settings.h"
using content::BrowserThread;
using printing::PageRanges;
using printing::PrintSettings;
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 {
CefRefPtr<CefBrowserHostBase> GetBrowserForContext(
printing::PrintingContextLinux* context) {
// The print preview dialog won't have a valid child ID.
2023-01-02 23:59:03 +01:00
if (!frame_util::IsValidChildId(context->render_process_id())) {
return nullptr;
2023-01-02 23:59:03 +01:00
}
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
return CefBrowserHostBase::GetBrowserForGlobalId(frame_util::MakeGlobalId(
context->render_process_id(), context->render_frame_id()));
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
}
CefRefPtr<CefPrintHandler> GetPrintHandlerForBrowser(
CefRefPtr<CefBrowserHostBase> browser) {
if (browser) {
if (auto client = browser->GetClient()) {
return client->GetPrintHandler();
}
}
return nullptr;
}
} // namespace
class CefPrintDialogCallbackImpl : public CefPrintDialogCallback {
public:
explicit CefPrintDialogCallbackImpl(CefRefPtr<CefPrintDialogLinux> dialog)
: dialog_(dialog) {}
CefPrintDialogCallbackImpl(const CefPrintDialogCallbackImpl&) = delete;
CefPrintDialogCallbackImpl& operator=(const CefPrintDialogCallbackImpl&) =
delete;
void Continue(CefRefPtr<CefPrintSettings> settings) override {
if (CEF_CURRENTLY_ON_UIT()) {
if (dialog_.get()) {
dialog_->OnPrintContinue(settings);
dialog_ = nullptr;
}
} else {
CEF_POST_TASK(CEF_UIT,
base::BindOnce(&CefPrintDialogCallbackImpl::Continue, this,
settings));
}
}
void Cancel() override {
if (CEF_CURRENTLY_ON_UIT()) {
if (dialog_.get()) {
dialog_->OnPrintCancel();
dialog_ = nullptr;
}
} else {
CEF_POST_TASK(CEF_UIT,
base::BindOnce(&CefPrintDialogCallbackImpl::Cancel, this));
}
}
void Disconnect() { dialog_ = nullptr; }
private:
CefRefPtr<CefPrintDialogLinux> dialog_;
IMPLEMENT_REFCOUNTING(CefPrintDialogCallbackImpl);
};
class CefPrintJobCallbackImpl : public CefPrintJobCallback {
public:
explicit CefPrintJobCallbackImpl(CefRefPtr<CefPrintDialogLinux> dialog)
: dialog_(dialog) {}
CefPrintJobCallbackImpl(const CefPrintJobCallbackImpl&) = delete;
CefPrintJobCallbackImpl& operator=(const CefPrintJobCallbackImpl&) = delete;
void Continue() override {
if (CEF_CURRENTLY_ON_UIT()) {
if (dialog_.get()) {
dialog_->OnJobCompleted();
dialog_ = nullptr;
}
} else {
CEF_POST_TASK(CEF_UIT,
base::BindOnce(&CefPrintJobCallbackImpl::Continue, this));
}
}
void Disconnect() { dialog_ = nullptr; }
private:
CefRefPtr<CefPrintDialogLinux> dialog_;
IMPLEMENT_REFCOUNTING(CefPrintJobCallbackImpl);
};
CefPrintingContextLinuxDelegate::CefPrintingContextLinuxDelegate() = default;
printing::PrintDialogLinuxInterface*
CefPrintingContextLinuxDelegate::CreatePrintDialog(
printing::PrintingContextLinux* context) {
CEF_REQUIRE_UIT();
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
printing::PrintDialogLinuxInterface* interface = nullptr;
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
auto browser = GetBrowserForContext(context);
if (!browser) {
LOG(ERROR) << "No associated browser in CreatePrintDialog; using default "
"printing implementation.";
}
auto handler = GetPrintHandlerForBrowser(browser);
if (!handler) {
if (default_delegate_) {
interface = default_delegate_->CreatePrintDialog(context);
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
DCHECK(interface);
}
} else {
interface = new CefPrintDialogLinux(context, browser, handler);
}
if (!interface) {
LOG(ERROR) << "Null interface in CreatePrintDialog; printing will fail.";
}
return interface;
}
gfx::Size CefPrintingContextLinuxDelegate::GetPdfPaperSize(
printing::PrintingContextLinux* context) {
CEF_REQUIRE_UIT();
gfx::Size size;
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
auto browser = GetBrowserForContext(context);
if (!browser) {
LOG(ERROR) << "No associated browser in GetPdfPaperSize; using default "
"printing implementation.";
}
auto handler = GetPrintHandlerForBrowser(browser);
if (!handler) {
if (default_delegate_) {
size = default_delegate_->GetPdfPaperSize(context);
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
DCHECK(!size.IsEmpty());
}
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
} else {
const printing::PrintSettings& settings = context->settings();
CefSize cef_size = handler->GetPdfPaperSize(
browser.get(), settings.device_units_per_inch());
size.SetSize(cef_size.width, cef_size.height);
}
if (size.IsEmpty()) {
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
LOG(ERROR) << "Empty size value returned in GetPdfPaperSize; PDF printing "
"will fail.";
}
return size;
}
void CefPrintingContextLinuxDelegate::SetDefaultDelegate(
ui::PrintingContextLinuxDelegate* delegate) {
DCHECK(!default_delegate_);
default_delegate_ = delegate;
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
}
CefPrintDialogLinux::CefPrintDialogLinux(PrintingContextLinux* context,
CefRefPtr<CefBrowserHostBase> browser,
CefRefPtr<CefPrintHandler> handler)
: context_(context), browser_(browser), handler_(handler) {
CEF_REQUIRE_UIT();
DCHECK(context_);
DCHECK(browser_);
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
DCHECK(handler_);
// Paired with the ReleaseDialog() call.
AddRef();
handler->OnPrintStart(browser_.get());
}
CefPrintDialogLinux::~CefPrintDialogLinux() {
// It's not safe to dereference |context_| during the destruction of this
// object because the PrintJobWorker which owns |context_| may already have
// been deleted.
CEF_REQUIRE_UIT();
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
handler_->OnPrintReset(browser_.get());
}
void CefPrintDialogLinux::UseDefaultSettings() {
UpdateSettings(std::make_unique<PrintSettings>(), true);
}
void CefPrintDialogLinux::UpdateSettings(
std::unique_ptr<PrintSettings> settings) {
UpdateSettings(std::move(settings), false);
}
#if BUILDFLAG(ENABLE_OOP_PRINTING_NO_OOP_BASIC_PRINT_DIALOG)
void CefPrintDialogLinux::LoadPrintSettings(
const printing::PrintSettings& settings) {
// TODO(linux): Need to read data from |settings.system_print_dialog_data()|?
UseDefaultSettings();
}
#endif
void CefPrintDialogLinux::ShowDialog(
gfx::NativeView parent_view,
bool has_selection,
PrintingContextLinux::PrintSettingsCallback callback) {
CEF_REQUIRE_UIT();
callback_ = std::move(callback);
CefRefPtr<CefPrintDialogCallbackImpl> callback_impl(
new CefPrintDialogCallbackImpl(this));
if (!handler_->OnPrintDialog(browser_.get(), has_selection,
callback_impl.get())) {
callback_impl->Disconnect();
OnPrintCancel();
}
}
void CefPrintDialogLinux::PrintDocument(
const printing::MetafilePlayer& metafile,
const std::u16string& document_name) {
// This runs on the print worker thread, does not block the UI thread.
DCHECK(!CEF_CURRENTLY_ON_UIT());
// The document printing tasks can outlive the PrintingContext that created
// this dialog.
AddRef();
bool success = base::CreateTemporaryFile(&path_to_pdf_);
if (success) {
base::File file;
file.Initialize(path_to_pdf_,
base::File::FLAG_CREATE_ALWAYS | base::File::FLAG_WRITE);
success = metafile.SaveTo(&file);
file.Close();
2023-01-02 23:59:03 +01:00
if (!success) {
base::DeleteFile(path_to_pdf_);
2023-01-02 23:59:03 +01:00
}
}
if (!success) {
LOG(ERROR) << "Saving metafile failed";
// Matches AddRef() above.
Release();
return;
}
// No errors, continue printing.
CEF_POST_TASK(
CEF_UIT, base::BindOnce(&CefPrintDialogLinux::SendDocumentToPrinter, this,
document_name));
}
void CefPrintDialogLinux::ReleaseDialog() {
context_ = nullptr;
Release();
}
bool CefPrintDialogLinux::UpdateSettings(
std::unique_ptr<PrintSettings> settings,
bool get_defaults) {
CEF_REQUIRE_UIT();
CefRefPtr<CefPrintSettingsImpl> settings_impl(
new CefPrintSettingsImpl(std::move(settings), false));
handler_->OnPrintSettings(browser_.get(), settings_impl.get(), get_defaults);
context_->InitWithSettings(settings_impl->TakeOwnership());
return true;
}
void CefPrintDialogLinux::SendDocumentToPrinter(
const std::u16string& document_name) {
CEF_REQUIRE_UIT();
if (!handler_.get()) {
OnJobCompleted();
return;
}
CefRefPtr<CefPrintJobCallbackImpl> callback_impl(
new CefPrintJobCallbackImpl(this));
if (!handler_->OnPrintJob(browser_.get(), document_name, path_to_pdf_.value(),
callback_impl.get())) {
callback_impl->Disconnect();
OnJobCompleted();
}
}
void CefPrintDialogLinux::OnPrintContinue(
CefRefPtr<CefPrintSettings> settings) {
CefPrintSettingsImpl* impl =
static_cast<CefPrintSettingsImpl*>(settings.get());
context_->InitWithSettings(impl->TakeOwnership());
std::move(callback_).Run(printing::mojom::ResultCode::kSuccess);
}
void CefPrintDialogLinux::OnPrintCancel() {
std::move(callback_).Run(printing::mojom::ResultCode::kCanceled);
}
void CefPrintDialogLinux::OnJobCompleted() {
CEF_POST_BACKGROUND_TASK(base::GetDeleteFileCallback(path_to_pdf_));
// Printing finished. Matches AddRef() in PrintDocument();
Release();
}