[w3c/clipboard-apis] Clarify cancellation of pending clipboard writes on focus loss (Issue #254)

gastonrod created an issue (w3c/clipboard-apis#254)

I would like to confirm and explicitly specify the cancellation behavior discussed in [#161](https://github.com/w3c/clipboard-apis/issues/161).

My reading of the [WG discussion](https://github.com/w3c/clipboard-apis/issues/161#issuecomment-967301900) is that cancelling pending writes when the document loses focus was the favored direction. The [minutes ](https://github.com/w3c/clipboard-apis/issues/161#issuecomment-967301900) describe an implementation where leaving the tab rejects the pending write promise, followed by support for those rules.

[PR #158](https://github.com/w3c/clipboard-apis/pull/158) (linked to that issue) formalized the promise-based representation and write algorithms, but I could not find a step that cancels a pending write on focus loss.

The current [privacy requirement](https://w3c.github.io/clipboard-apis/#privacy-async) says:

> To help prevent abuse, this API must not be available unless the script
> is executing in the context of a document that has focus.

However, the current [`write()` algorithm](https://w3c.github.io/clipboard-apis/#dom-clipboard-write) checks permission before processing the representation promises and does not explicitly connect that requirement to cancellation during the asynchronous operation. This has been brought up in the past: [#203](https://github.com/w3c/clipboard-apis/issues/203) and [#78](https://github.com/w3c/clipboard-apis/issues/78).

### Example sequence

1. A focused document calls `navigator.clipboard.write()` with a `ClipboardItem` containing an unresolved data promise. Any applicable permission and user-activation requirements are satisfied at invocation.
2. The user switches to another tab or application.
3. The user copies different content there.
4. The original promise from (1) resolves and inserts content into the clipboard.

Without cancellation or a late focus check, the original operation could replace content the user copied elsewhere.

### Clarification requested

1. Should focus loss permanently cancel the pending write? For example, if the document loses focus and regains it before its data is ready, must the original operation still reject? Cancelling on focus loss and checking focus only when attempting to change the system clipboard give different results in this case.
2. When should rejection happen, and with which exception? Should the returned promise by `clipboard.write()` reject on focus loss, even if a representation promise never settles, or only when preparation resumes? Would `NotAllowedError` be the intended exception?

If cancellation is the intended behavior, could we work on adding explicit steps to the write algorithms and corresponding WPTs?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/254
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/254@github.com>