Bug 1852947 - Redesign the async clipboard read API; r=nika
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
2023-11-14 09:21:24 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#include "mozilla/ClipboardReadRequestParent.h"
|
|
|
|
|
|
|
|
#include "mozilla/dom/ContentParent.h"
|
|
|
|
#include "mozilla/net/CookieJarSettings.h"
|
|
|
|
#include "nsComponentManagerUtils.h"
|
|
|
|
#include "nsIClipboard.h"
|
|
|
|
#include "nsITransferable.h"
|
|
|
|
#include "nsWidgetsCID.h"
|
|
|
|
|
|
|
|
using mozilla::dom::ContentParent;
|
|
|
|
using mozilla::ipc::IPCResult;
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class ClipboardGetDataCallback final : public nsIAsyncClipboardRequestCallback {
|
|
|
|
public:
|
|
|
|
explicit ClipboardGetDataCallback(std::function<void(nsresult)>&& aCallback)
|
|
|
|
: mCallback(std::move(aCallback)) {}
|
|
|
|
|
|
|
|
// This object will never be held by a cycle-collected object, so it doesn't
|
|
|
|
// need to be cycle-collected despite holding alive cycle-collected objects.
|
|
|
|
NS_DECL_ISUPPORTS
|
|
|
|
|
|
|
|
// nsIAsyncClipboardRequestCallback
|
|
|
|
NS_IMETHOD OnComplete(nsresult aResult) override {
|
|
|
|
mCallback(aResult);
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
|
|
|
~ClipboardGetDataCallback() = default;
|
|
|
|
|
|
|
|
std::function<void(nsresult)> mCallback;
|
|
|
|
};
|
|
|
|
|
|
|
|
NS_IMPL_ISUPPORTS(ClipboardGetDataCallback, nsIAsyncClipboardRequestCallback)
|
|
|
|
|
|
|
|
static Result<nsCOMPtr<nsITransferable>, nsresult> CreateTransferable(
|
|
|
|
const nsTArray<nsCString>& aTypes) {
|
|
|
|
nsresult rv;
|
|
|
|
nsCOMPtr<nsITransferable> trans =
|
|
|
|
do_CreateInstance("@mozilla.org/widget/transferable;1", &rv);
|
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
return Err(rv);
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_TRY(trans->Init(nullptr));
|
|
|
|
// The private flag is only used to prevent the data from being cached to the
|
|
|
|
// disk. The flag is not exported to the IPCDataTransfer object.
|
|
|
|
// The flag is set because we are not sure whether the clipboard data is used
|
|
|
|
// in a private browsing context. The transferable is only used in this scope,
|
|
|
|
// so the cache would not reduce memory consumption anyway.
|
|
|
|
trans->SetIsPrivateData(true);
|
|
|
|
// Fill out flavors for transferable
|
|
|
|
for (uint32_t t = 0; t < aTypes.Length(); t++) {
|
|
|
|
MOZ_TRY(trans->AddDataFlavor(aTypes[t].get()));
|
|
|
|
}
|
|
|
|
|
|
|
|
return std::move(trans);
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
IPCResult ClipboardReadRequestParent::RecvGetData(
|
|
|
|
const nsTArray<nsCString>& aFlavors, GetDataResolver&& aResolver) {
|
|
|
|
bool valid = false;
|
2024-06-20 07:36:40 +00:00
|
|
|
if (NS_FAILED(mClipboardDataSnapshot->GetValid(&valid)) || !valid) {
|
Bug 1852947 - Redesign the async clipboard read API; r=nika
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
2023-11-14 09:21:24 +00:00
|
|
|
Unused << PClipboardReadRequestParent::Send__delete__(this);
|
|
|
|
aResolver(NS_ERROR_FAILURE);
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create transferable
|
|
|
|
auto result = CreateTransferable(aFlavors);
|
|
|
|
if (result.isErr()) {
|
|
|
|
aResolver(result.unwrapErr());
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
nsCOMPtr<nsITransferable> trans = result.unwrap();
|
|
|
|
RefPtr<ClipboardGetDataCallback> callback =
|
|
|
|
MakeRefPtr<ClipboardGetDataCallback>([self = RefPtr{this},
|
|
|
|
resolver = std::move(aResolver),
|
|
|
|
trans,
|
|
|
|
manager = mManager](nsresult aRv) {
|
|
|
|
if (NS_FAILED(aRv)) {
|
|
|
|
bool valid = false;
|
2024-06-20 07:36:40 +00:00
|
|
|
if (NS_FAILED(self->mClipboardDataSnapshot->GetValid(&valid)) ||
|
Bug 1852947 - Redesign the async clipboard read API; r=nika
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
2023-11-14 09:21:24 +00:00
|
|
|
!valid) {
|
|
|
|
Unused << PClipboardReadRequestParent::Send__delete__(self);
|
|
|
|
}
|
|
|
|
resolver(aRv);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dom::IPCTransferableData ipcTransferableData;
|
|
|
|
nsContentUtils::TransferableToIPCTransferableData(
|
|
|
|
trans, &ipcTransferableData, false /* aInSyncMessage */, manager);
|
|
|
|
resolver(std::move(ipcTransferableData));
|
|
|
|
});
|
2024-06-20 07:36:40 +00:00
|
|
|
nsresult rv = mClipboardDataSnapshot->GetData(trans, callback);
|
Bug 1852947 - Redesign the async clipboard read API; r=nika
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
2023-11-14 09:21:24 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
callback->OnComplete(rv);
|
|
|
|
}
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
2024-10-28 22:37:56 +00:00
|
|
|
IPCResult ClipboardReadRequestParent::RecvGetDataSync(
|
|
|
|
const nsTArray<nsCString>& aFlavors,
|
|
|
|
dom::IPCTransferableDataOrError* aTransferableDataOrError) {
|
|
|
|
bool valid = false;
|
|
|
|
if (NS_FAILED(mClipboardDataSnapshot->GetValid(&valid)) || !valid) {
|
|
|
|
Unused << PClipboardReadRequestParent::Send__delete__(this);
|
|
|
|
*aTransferableDataOrError = NS_ERROR_FAILURE;
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create transferable
|
|
|
|
auto result = CreateTransferable(aFlavors);
|
|
|
|
if (result.isErr()) {
|
|
|
|
*aTransferableDataOrError = result.unwrapErr();
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
nsCOMPtr<nsITransferable> trans = result.unwrap();
|
|
|
|
nsresult rv = mClipboardDataSnapshot->GetDataSync(trans);
|
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
*aTransferableDataOrError = rv;
|
|
|
|
if (NS_FAILED(mClipboardDataSnapshot->GetValid(&valid)) || !valid) {
|
|
|
|
Unused << PClipboardReadRequestParent::Send__delete__(this);
|
|
|
|
}
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
dom::IPCTransferableData ipcTransferableData;
|
|
|
|
nsContentUtils::TransferableToIPCTransferableData(
|
|
|
|
trans, &ipcTransferableData, true /* aInSyncMessage */, mManager);
|
|
|
|
*aTransferableDataOrError = std::move(ipcTransferableData);
|
|
|
|
return IPC_OK();
|
|
|
|
}
|
|
|
|
|
Bug 1852947 - Redesign the async clipboard read API; r=nika
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
2023-11-14 09:21:24 +00:00
|
|
|
} // namespace mozilla
|