1
1
This proposal is an early design sketch by ChromeOS team to describe the problem below and solicit feedback on the
2
2
proposed solution. It has not been approved to ship in Chrome.
3
3
4
- # Explainer: ` navigator.clipboard.contentsID () `
4
+ # Explainer: ` navigator.clipboard.contentsId () `
5
5
6
6
## Authors:
7
7
@@ -44,7 +44,7 @@ so that:
44
44
2 . When a user copies something on the remote machine and switches away from the VDI app, they can paste the copied
45
45
content locally.
46
46
47
- Without ` contentsID ()` , there are two primary ways to achieve the first scenario:
47
+ Without ` contentsId ()` , there are two primary ways to achieve the first scenario:
48
48
49
49
- Upon refocusing the VDI app, automatically send the content from the local clipboard to the remote machine.
50
50
- Upon refocusing the VDI app, read the clipboard contents, compare them with the last known state, and send to the
66
66
[ Android] ( https://developer.android.com/reference/android/content/ClipboardManager.OnPrimaryClipChangedListener ) and
67
67
[ iOS] ( https://developer.apple.com/documentation/uikit/uipasteboard/changecount ) ) offer efficient ways to track clipboard content changes
68
68
without directly reading the data. This is often achieved through clipboard sequence numbers or change notifications.
69
- The ` navigator.clipboard.contentsID () ` API aims to leverage these capabilities. It allows websites to request a numeric
69
+ The ` navigator.clipboard.contentsId () ` API aims to leverage these capabilities. It allows websites to request a numeric
70
70
token (a 128-bit integer) representing the current clipboard state. If this token differs from a previously retrieved
71
71
one, it indicates that the clipboard contents have changed between the two calls. Importantly, this operation has a
72
72
constant time complexity (O(1)), independent of the clipboard's size. Therefore, even frequent checks (e.g., on window
@@ -88,14 +88,14 @@ refocus) remain efficient, even when dealing with large amounts of copied data.
88
88
89
89
One of the goals of this API is to enable cross-app synchronization of clipboard \- so this should be as close to the
90
90
stability of the clipboard itself as possible. So, every site under the same browser process should get the same token
91
- from calling ` contentsID ()` .
91
+ from calling ` contentsId ()` .
92
92
93
93
## How to use it?
94
94
95
95
Frankly, quite straightforwardly. Signature of the method will look somewhat like this:
96
96
97
97
``` javascript
98
- Promise < BigInt > contentsID ();
98
+ Promise < BigInt > contentsId ();
99
99
```
100
100
101
101
So in the mentioned VDI case, the code could look somewhat like this:
@@ -106,7 +106,7 @@ var lastToken = null;
106
106
// Handler called on every window refocus.
107
107
// It checks if it's necessary to sync clipboard contents to remote.
108
108
window .addEventListener (" focus" , () => {
109
- navigator .clipboard .contentsID ().then ((token ) => {
109
+ navigator .clipboard .contentsId ().then ((token ) => {
110
110
if (token !== lastToken) {
111
111
// Clipboard contents have changed!
112
112
// Send to remote machine
@@ -118,7 +118,7 @@ window.addEventListener("focus", () => {
118
118
// Function that is called by the client app when user copies something on remote.
119
119
async function onRemoteClipboardChanged (remoteClipboardItems ) {
120
120
await navigator .clipboard .write (remoteClipboardItems);
121
- lastToken = await navigator .clipboard .contentsID ();
121
+ lastToken = await navigator .clipboard .contentsId ();
122
122
}
123
123
```
124
124
@@ -136,7 +136,7 @@ ways:
136
136
clipboard and updating the last-known token value.
137
137
138
138
Both however would require some synchronization of the handler and ` onRemoteClipboardChanged ` to prevent handlers
139
- getting between ` write ` and ` contentsID ` .
139
+ getting between ` write ` and ` contentsId ` .
140
140
141
141
** Note:** In any case, this will be in some degree prone to inherent race conditions due to lack of clipboard atomic
142
142
operations \- which will show themselves mostly in case of user switching apps very rapidly. This API exists in order to
@@ -165,7 +165,7 @@ and standardized, it operates differently. Instead of determining if a change ha
165
165
it provides real-time notifications for every change, without detailed information about the cause. Therefore, if your
166
166
app also writes to the clipboard, it can be challenging to determine whether you or another source caused the change
167
167
(especially with multiple windows/tabs of the same app open), potentially leading to unnecessary data transfers or
168
- having to implement comparison anyway. In case of ` contentsID ()` , you can save the new token just after writing \- and
168
+ having to implement comparison anyway. In case of ` contentsId ()` , you can save the new token just after writing \- and
169
169
it will be irrelevant for all active tabs/windows irrelevant what caused the change, only that this change is already in
170
170
sync with the remote and no action is needed.
171
171
@@ -177,7 +177,7 @@ There are several ways in which the token could look like, including:
177
177
2 . Timestamp of the last change (or call that detected it)
178
178
3 . Hash of the clipboard contents
179
179
4 . Random 128-bit number without any specified scheme or significance \- other than “after something is written to the
180
- clipboard, ` contentsID ()` should yield a different value than it did before the write”
180
+ clipboard, ` contentsId ()` should yield a different value than it did before the write”
181
181
182
182
Preferred approach is 4, for the following reasons:
183
183
0 commit comments