[madeofpalk]

I think Chrome's reasoning for this is completely fair:

> navigator.clipboard is only intended to be used in a focused document, which is not possible for service workers. Therefore, I don't anticipate any intended support for navigator.clipboard.read on service workers

I don't think a browser extension, which I personally consider it sit in between "native app" and "website" in terms of privilege hierarchy, should be able to arbitrarily read the operating system clipboard silently in the background.

[fosefx]

My use case: A background script, sorry, Service Worker registers a Context Menu Entry. When the user clicks on it it fetches some stuff an copies a link to clipboard.

Using MV3 as it is this is not possible.

As someone in the thread said, it is not really feasible to try to find all ways that user interaction can trigger code that requires clipboard access. If that is the route Google want to go down it will take years of people reporting new ways the system does not work until it is usable imo.

[madeofpalk]

"User interaction to perform an action" im pretty sure is a part of the HTML/JS spec. For example, browsers on iOS will not let you play a video unless in response to a "user action".

[cobertos]

Read farther

> historically when I've tried using navigator.clipboard from the MV2 background page, it would pop up a separate permissions dialog (presumably the one that would appear for standard non-extension contexts that are requesting clipboard access), despite the extension having clipboard permissions.