gecko-dev/widget/nsIClipboard.idl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

250 строки
10 KiB
Plaintext
Исходник Обычный вид История

1999-09-04 23:57:42 +04:00
/* -*- Mode: IDL; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
*
2012-05-21 15:12:37 +04:00
* 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/. */
1999-09-04 23:57:42 +04:00
#include "nsISupports.idl"
#include "nsITransferable.idl"
#include "nsIClipboardOwner.idl"
interface nsIArray;
1999-09-04 23:57:42 +04:00
webidl WindowContext;
[scriptable, builtinclass, uuid(801e2318-c8fa-11ed-afa1-0242ac120002)]
interface nsIAsyncSetClipboardData : nsISupports {
/**
* Provide the data for the set request.
*
* @param aTransferable
* The transferable contains the data to be written.
* @param aOwner [optional]
* The owner of the transferable.
*/
void setData(in nsITransferable aTransferable, [optional] in nsIClipboardOwner aOwner);
/**
* Abort the request to set data.
*
* @param aReason
* The reason for the abort, can not be NS_OK.
*/
void abort(in nsresult aReason);
};
[scriptable, function, uuid(78f7c18e-c8fa-11ed-afa1-0242ac120002)]
interface nsIAsyncClipboardRequestCallback : nsISupports
{
/**
* Indicates that the clipboard request has either succeeded, been canceled or
* rejected.
*
* @param aResult
* The result of the request. NS_OK if successful, or another value
* that indicates the reason for failure or cancellation.
*/
void onComplete(in nsresult aResult);
};
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 12:21:24 +03:00
[scriptable, builtinclass, uuid(c18ea2f7-6b6f-4a38-9ab3-a8781fdfcc39)]
interface nsIAsyncGetClipboardData : nsISupports {
/**
* Determines whether this request is still valid (e.g., the clipboard content
* associated with this request is not stale).
*/
readonly attribute boolean valid;
/**
* The available flavors in the clipboard.
*/
readonly attribute Array<ACString> flavorList;
/**
* Filters the flavors that `aTransferable` can import (see
* `nsITransferable::flavorsTransferableCanImport`). Every specified flavors
* must exist in `flavorList`, or the request will be rejected. If the request
* remains valid, it retrieves the data for the first flavor. The data is then
* set for `aTransferable`.
*
* @param aTransferable
* The transferable which contains the flavors to be read.
* @param aCallback
* The nsIAsyncClipboardRequestCallback to be invoked once the get
* request is either successfully completed or rejected.
* @result NS_OK if no errors
*/
void getData(in nsITransferable aTransferable,
in nsIAsyncClipboardRequestCallback aCallback);
};
[scriptable, uuid(ce23c1c4-58fd-4c33-8579-fa0796d9652c)]
interface nsIAsyncClipboardGetCallback : nsISupports
{
/**
* Indicates that the clipboard get request has succeeded.
*/
void onSuccess(in nsIAsyncGetClipboardData aAsyncGetClipboardData);
/**
* Indicates that the clipboard get request has rejected.
*
* @param aResult
* The reason for the rejection, can not be NS_OK.
*/
void onError(in nsresult aResult);
};
[scriptable, builtinclass, uuid(ceaa0047-647f-4b8e-ad1c-aff9fa62aa51)]
1999-09-04 23:57:42 +04:00
interface nsIClipboard : nsISupports
{
const long kSelectionClipboard = 0;
const long kGlobalClipboard = 1;
const long kFindClipboard = 2;
// Used to cache current selection on (nsClipboard) for macOS service menu.
const long kSelectionCache = 3;
%{ C++
static const uint32_t kClipboardTypeCount = kSelectionCache + 1;
%}
1999-09-04 23:57:42 +04:00
/**
* Given a transferable, set the data on the native clipboard
*
* @param aTransferable The transferable
* @param anOwner The owner of the transferable
* @param aWhichClipboard Specifies the clipboard to which this operation applies.
* @param aSettingWindowContext [optional]
* The window context that is setting the clipboard, if any. This is used
* to possibly bypass Content Analysis if a set clipboard and get clipboard
* operation are done on the same page.
* @result NS_OK if no errors
1999-09-04 23:57:42 +04:00
*/
void setData (in nsITransferable aTransferable, in nsIClipboardOwner anOwner,
in long aWhichClipboard, [optional] in WindowContext aSettingWindowContext);
1999-09-04 23:57:42 +04:00
/**
* Requests setting data to the native clipboard. The actual set occurs
* when the data is provided by calling nsIAsyncSetClipboardData::setData().
* The result will be notified by nsIClipboardCallback. A new set request
* will cancel any prior pending requests, if any exist.
*
* @param aWhichClipboard
* Specifies the clipboard to which this operation applies.
* @param aSettingWindowContext [optional]
* The window context that is setting the clipboard, if any. This is used
* to possibly bypass Content Analysis if a set clipboard and get clipboard
* operation are done on the same page.
* @param aCallback [optional]
* The callback object that will be notified upon completion.
* @return nsIAsyncSetClipboardData
* The write request object. The actual write will occur when the
* data is provided by calling nsIAsyncSetClipboardData::setData().
*/
nsIAsyncSetClipboardData asyncSetData(in long aWhichClipboard,
[optional] in WindowContext aSettingWindowContext,
[optional] in nsIAsyncClipboardRequestCallback aCallback);
1999-09-04 23:57:42 +04:00
/**
* Filters the flavors aTransferable can import (see
* `nsITransferable::flavorsTransferableCanImport`) and gets the data for the
* first flavor. That data is set for aTransferable.
1999-09-04 23:57:42 +04:00
*
* @param aTransferable The transferable
* @param aWhichClipboard Specifies the clipboard to which this operation applies.
* @param aRequestingWindowContext [optional]
* The window context window that is requesting the clipboard, which is
* used for content analysis. Passing null means that the content is
* exempt from content analysis. (for example, scripted clipboard read by
* system code) This parameter should not be null when calling this from a
* content process.
* @result NS_OK if no errors
1999-09-04 23:57:42 +04:00
*/
void getData ( in nsITransferable aTransferable, in long aWhichClipboard, [optional] in WindowContext aRequestingWindowContext) ;
1999-09-04 23:57:42 +04:00
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 12:21:24 +03:00
/**
* Requests getting data asynchronously from the native clipboard. This does
* not actually retrieve the data, but returns a nsIAsyncGetClipboardData
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 12:21:24 +03:00
* contains current avaiable data formats. If the native clipboard is
* updated, either by us or other application, the existing
* nsIAsyncGetClipboardData becomes invalid.
*
* @param aFlavorList
* Specific data formats ('flavors') that can be retrieved from the
* clipboard.
* @param aWhichClipboard
* Specifies the clipboard to which this operation applies.
* @param aCallback
* The callback object that will be notified upon completion.
* @result NS_OK if no errors
*/
void asyncGetData(in Array<ACString> aFlavorList,
in long aWhichClipboard,
in WindowContext aRequestingWindowContext,
in nsIPrincipal aRequestingPrincipal,
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 12:21:24 +03:00
in nsIAsyncClipboardGetCallback aCallback);
/**
* Requests getting data from the native clipboard. This does not actually
* retreive the data, but returns a nsIAsyncGetClipboardData contains
* current avaiable data formats. If the native clipboard is updated, either
* by us or other application, the existing nsIAsyncGetClipboardData becomes
* invalid.
*
* @param aFlavorList
* Specific data formats ('flavors') that can be retrieved from the
* clipboard.
* @param aWhichClipboard
* Specifies the clipboard to which this operation applies.
* @param aRequestingWindowContext [optional]
* The window context window that is requesting the clipboard, which is
* used for content analysis. Passing null means that the content is
* exempt from content analysis. (for example, scripted clipboard read by
* system code) This parameter should not be null when calling this from a
* content process.
* @return nsIAsyncSetClipboardData if successful.
* @throws if the request can not be made.
*/
nsIAsyncGetClipboardData getDataSnapshotSync(in Array<ACString> aFlavorList,
in long aWhichClipboard,
[optional] in WindowContext aRequestingWindowContext);
1999-09-04 23:57:42 +04:00
/**
* This empties the clipboard and notifies the clipboard owner.
* This empties the "logical" clipboard. It does not clear the native clipboard.
*
* @param aWhichClipboard Specifies the clipboard to which this operation applies.
1999-09-04 23:57:42 +04:00
* @result NS_OK if successful.
*/
void emptyClipboard ( in long aWhichClipboard ) ;
1999-09-04 23:57:42 +04:00
/**
* This provides a way to give correct UI feedback about, for instance, a paste
* should be allowed. It does _NOT_ actually retreive the data and should be a very
* inexpensive call. All it does is check if there is data on the clipboard matching
* any of the flavors in the given list.
*
* @param aFlavorList An array of ASCII strings.
* @param aWhichClipboard Specifies the clipboard to which this operation applies.
1999-09-04 23:57:42 +04:00
* @outResult - if data is present matching one of
* @result NS_OK if successful.
*/
boolean hasDataMatchingFlavors ( in Array<ACString> aFlavorList,
in long aWhichClipboard ) ;
/**
* Allows clients to determine if the implementation supports the concept of a
* separate clipboard.
*
* @param aWhichClipboard Specifies the clipboard to which this operation applies.
* @outResult true if the implementaion supports specific clipboard type.
* @result NS_OK if successful.
*/
[infallible]
boolean isClipboardTypeSupported(in long aWhichClipboard);
};