This is a sync version of `nsIClipboard.asyncGetData`, which can be used for
synchronous clipboard APIs, e.g. DataTransfer, to support the clipboard seqence
number concept, see bug 1879401.
Differential Revision: https://phabricator.services.mozilla.com/D201364
This is a sync version of `nsIClipboard.asyncGetData`, which can be used for
synchronous clipboard APIs, e.g. DataTransfer, to support the clipboard seqence
number concept, see bug 1879401.
Depends on D201657
Differential Revision: https://phabricator.services.mozilla.com/D201364
This is a sync version of `nsIClipboard.asyncGetData`, which can be used for
synchronous clipboard APIs, e.g. DataTransfer, to support the clipboard seqence
number concept, see bug 1879401.
Depends on D201657
Differential Revision: https://phabricator.services.mozilla.com/D201364
This is a sync version of `nsIClipboard.asyncGetData`, which can be used for
synchronous clipboard APIs, e.g. DataTransfer, to support the clipboard seqence
number concept, see bug 1879401.
Depends on D201657
Differential Revision: https://phabricator.services.mozilla.com/D201364
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
This patch makes the clipboard context menu trigger from the parent process rather
than the content process. A new method, `confirmUserPaste`, is added on `nsIPromptService`
to trigger frontend UI.
The behavior of handling multiple requests should remain unchanged, new tests are
added to ensure that.
Differential Revision: https://phabricator.services.mozilla.com/D190405
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
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
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
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
Since IPCDataTransfer* is actually used for nsITransferable, so rename them to
IPCTransferable* as follows,
- Rename IPCDataTransfer to IPCTransferableData.
- Rename IPCDataTransferItem to IPCTransferableDataItem.
- Rename IPCDataTransferData to IPCTransferableDataType.
- Rename IPCDataTransferString to IPCTransferableDataString.
- Rename IPCDataTransferCString to IPCTransferableDataCString.
- Rename IPCDataTransferInputStream to IPCTransferableDataInputStream.
- Rename IPCDataTransferImageContainer to IPCTransferableDataImageContainer.
- Rename IPCDataTransferBlob to IPCTransferableDataBlob.
Differential Revision: https://phabricator.services.mozilla.com/D178069
Since IPCDataTransfer* is actually used for nsITransferable, so rename them to
IPCTransferable* as follows,
- Rename IPCDataTransfer to IPCTransferableData.
- Rename IPCDataTransferItem to IPCTransferableDataItem.
- Rename IPCDataTransferData to IPCTransferableDataType.
- Rename IPCDataTransferString to IPCTransferableDataString.
- Rename IPCDataTransferCString to IPCTransferableDataCString.
- Rename IPCDataTransferInputStream to IPCTransferableDataInputStream.
- Rename IPCDataTransferImageContainer to IPCTransferableDataImageContainer.
- Rename IPCDataTransferBlob to IPCTransferableDataBlob.
Differential Revision: https://phabricator.services.mozilla.com/D178069
Since IPCDataTransfer* is actually used for nsITransferable, so rename them to
IPCTransferable* as follows,
- Rename IPCDataTransfer to IPCTransferableData.
- Rename IPCDataTransferItem to IPCTransferableDataItem.
- Rename IPCDataTransferData to IPCTransferableDataType.
- Rename IPCDataTransferString to IPCTransferableDataString.
- Rename IPCDataTransferCString to IPCTransferableDataCString.
- Rename IPCDataTransferInputStream to IPCTransferableDataInputStream.
- Rename IPCDataTransferImageContainer to IPCTransferableDataImageContainer.
- Rename IPCDataTransferBlob to IPCTransferableDataBlob.
Differential Revision: https://phabricator.services.mozilla.com/D178069
The Async Clipboard API now allows using arbitrary promises for passing write data,
potentially enabling websites to delay writing data to an arbitrary future, which
may surprise the user. This patch introduces a solution: a new write request will
automatically cancel any previous pending request.
To implement that, this patch introduces a new method to nsIClipboard, new XPCOM
interfaces, and new IPC to efficiently track individual write requests. Additionally,
a new helper base class, ClipboardSetDataHelper, is introduced in widget to facilitate
platform code sharing.
Differential Revision: https://phabricator.services.mozilla.com/D174090
This prevents a11y from getting instantiated shortly after clipboard paste, in
order to prevent hangs with the Windows 11 suggested actions feature.
When combined with the previous patch, the behavior is the following:
* For users with a11y already-enabled:
* No hang (due to clipboard flush).
* Quick actions menu is positioned at selection offset.
* For users with a11y disabled (most):
* No hang (due to no a11y instantiation + clipboard flush).
* Quick actions menu is positioned at pointer (cursor) offset.
Co-Authored-By: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D160652
Depends on D160646
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
Edgar Chen
Cristian Tuns
Norisz Fay
Natalia Csoregi
Greg Stoll
Noemi Erli
Iulian Moraru
Tom Schuster
Stanca Serban
Tom Schuster
James Teh
Nika Layzell
Marian-Vasile Laza
Christian Holler