This basically makes the macOS behave the same as other platform (currently only
macOS would read data from clipboard cache). And also this would ensure behavior
doesn't change if one day we would like to enable reading-from-clipboard-cache
on other platforms as well.
Differential Revision: https://phabricator.services.mozilla.com/D203893
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
And don't allow new request being associated with existing pending request if
the requests are from different origin.
This patch also set proper principal to nsItransferable for clipboard write in
various cases,
- Copy image via context menu.
- Copy current selection via keyboard shortcut or context menu.
- Data is provided by script when copy operation is triggered via keyboard
shortcut or context menu.
- Clipboard data is put via async clipboard.
Depends on D190761
Differential Revision: https://phabricator.services.mozilla.com/D190796
Displaying the paste context menu for background tabs can be surprising and
confusing for users, so we reject the request and don't allow it being associated
with existing pending request.
Depends on D190405
Differential Revision: https://phabricator.services.mozilla.com/D190761
And don't allow new request being associated with existing pending request if
the requests are from different origin.
This patch also set proper principal to nsItransferable for clipboard write in
various cases,
- Copy image via context menu.
- Copy current selection via keyboard shortcut or context menu.
- Data is provided by script when copy operation is triggered via keyboard
shortcut or context menu.
- Clipboard data is put via async clipboard.
Depends on D190761
Differential Revision: https://phabricator.services.mozilla.com/D190796
Displaying the paste context menu for background tabs can be surprising and
confusing for users, so we reject the request and don't allow it being associated
with existing pending request.
Depends on D190405
Differential Revision: https://phabricator.services.mozilla.com/D190761
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
After bug 1851817, all platforms uses nsBaseClipboard as base class and clipboard
owner is handled there, so nsIClipboardOwner parameter is unused.
Differential Revision: https://phabricator.services.mozilla.com/D190236
Now all platform uses nsBaseClipboard, so we could just merge ClipboardSetDataHelper
into nsBaseClipboard.
Depends on D188252
Differential Revision: https://phabricator.services.mozilla.com/D188253
This is mainly added for GTK which supports getting clipboard data asynchrously.
For other platforms that don't support asynchrously reading, they could use
the default implementation which just wraps the `GetNativeClipboardData` instead.
Depends on D188249
Differential Revision: https://phabricator.services.mozilla.com/D188250
This is mainly added for GTK which supports getting clipboard data asynchrously.
For other platforms that don't support asynchrously reading, they could use
the default implementation which just wraps the `HasNativeClipboardDataMatchingFlavors`
instead.
Differential Revision: https://phabricator.services.mozilla.com/D188249
Now all platform uses nsBaseClipboard, so we could just merge ClipboardSetDataHelper
into nsBaseClipboard.
Depends on D188252
Differential Revision: https://phabricator.services.mozilla.com/D188253
This is mainly added for GTK which supports getting clipboard data asynchrously.
For other platforms that don't support asynchrously reading, they could use
the default implementation which just wraps the `GetNativeClipboardData` instead.
Depends on D188249
Differential Revision: https://phabricator.services.mozilla.com/D188250
This is mainly added for GTK which supports getting clipboard data asynchrously.
For other platforms that don't support asynchrously reading, they could use
the default implementation which just wraps the `HasNativeClipboardDataMatchingFlavors`
instead.
Differential Revision: https://phabricator.services.mozilla.com/D188249
