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
The MOZ_DIAGNOSTIC_ASSERT is added to identify the scenarios where we
might run into this check. From the crash report, this could occur
when we attempt to retry OleSetClipboard, which could be due to the
clipboard being opened by another application at the moment.
Previously, nsBaseClipboard used to set clipboard owner before it calls
into OleSetClipboard, see
https://searchfox.org/mozilla-central/rev/db616599807ac9acda96df74d24bcb25f3ba44e1/widget/nsBaseClipboard.cpp#181.
So we need to use `mIgnoreEmptyNotification` to prevent the clipboard
owner from being cleared in such case.
However, after https://phabricator.services.mozilla.com/D178777,
nsBaseClipboard now set clipboard owner after OleSetClipboard succeed,
so `mIgnoreEmptyNotification` should no longer be necessary. This patch
updates the MOZ_DIAGNOSTIC_ASSERT to verify this, if there is no
reported crashes, I believe we can safely remove
`mIgnoreEmptyNotification`.
Differential Revision: https://phabricator.services.mozilla.com/D182907
mEmptyingForSetData flag can be removed since it's used for clearing
cache data without emptying system clipboard and now we could just call
ClipboardCache::Clear().
Depends on D179999
Differential Revision: https://phabricator.services.mozilla.com/D180000
This patch introduce a preference for getting the data from cache
directly which is enabled on Mac only. And now we really support getting
data from cache for each type simultaneously, instead of only using the
one that has the latest cached transferable.
Depends on D178777
Differential Revision: https://phabricator.services.mozilla.com/D179993
We also need to update clipboard cache after setting native clipboard,
in order to obtain the correct clipboard change count.
Differential Revision: https://phabricator.services.mozilla.com/D178777
mEmptyingForSetData flag can be removed since it's used for clearing
cache data without emptying system clipboard and now we could just call
ClipboardCache::Clear().
Depends on D179999
Differential Revision: https://phabricator.services.mozilla.com/D180000
This patch introduce a preference for getting the data from cache
directly which is enabled on Mac only. And now we really support getting
data from cache for each type simultaneously, instead of only using the
one that has the latest cached transferable.
Depends on D178777
Differential Revision: https://phabricator.services.mozilla.com/D179993
We also need to update clipboard cache after setting native clipboard,
in order to obtain the correct clipboard change count.
Differential Revision: https://phabricator.services.mozilla.com/D178777
Calling it in destructor doesn't work as expected at all, since it's a virtual
function. Furthermore, it doesn't make sense to clear clipboard data every time
Firefox is closed.
Differential Revision: https://phabricator.services.mozilla.com/D178697
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
Edgar Chen
Cristian Tuns
Noemi Erli
Norisz Fay
Sandor Molnar
Cristina Horotan