Cannot read clipboard from service worker in a MV3 chrome extension (2020)
1–10 of 56 posts
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#2If I'm reading this correctly, extension developers want a way to read the user clipboard with a separate permission dialog than having to also request the ability to inject scripts into pages? If that is the case I can partially see why this is the way it is. The clipboard reading permission is part of the privacy controls built into the browser. So with page injection, the extension would have to request permission for sites that it wants to read the clipboard from. Otherwise, a separate dialog would give unhindered access to read from the clipboard. Am I understanding that correctly?
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#3Does any one have a sense of the likelihood that Google extends the original timeline for this changeover? How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet?
My company has two Chrome extensions, one of which is partly updated, and the other of which we haven't started yet. We have no idea what we'll discover when we begin the process of updating the second one, and we've been burned by Google's 'upgrades' in the past (Google Docs canvas-based rendering comes to mind). The worst-case scenario is that it is either impossible to migrate, or that it would cost so much that it would wipe out years of revenue.
I've talked with others in the accessibility space, and they are concerned about how this forced migration will impact the market for 'niche' tools like accessibility extensions. They may simply cease to exist. Hopefully Brave or other Chromium browsers will continue to allow legacy extensions.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#4Does any one have a sense of the likelihood that Google extends the original timeline for this changeover? How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet? My company has two Chrome extensions, one of which is partly updated, and the other of which we haven't started yet. We have no idea what we'll discover when we begin the process of updating t…
How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet?
Big Tech has been behaving like this for a while now. It's clear that they only care about their own interests (partly $$$, partly ideological), not yours.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#5Does any one have a sense of the likelihood that Google extends the original timeline for this changeover? How can you force everyone to update their software (in some cases overhaul) to a new system that isn't fully built yet? My company has two Chrome extensions, one of which is partly updated, and the other of which we haven't started yet. We have no idea what we'll discover when we begin the process of updating t…
It's google the graveyard and 69 chat apps memes are real. If you have the chance don't build anything on google services. Remember AMP? There were like AMP agencies popping up when it was introduced lol
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#6> Thanks for the issue....
> Thanks.....
Aside: Do people know that trailing "..." tends to communicate annoyance or sarcasm? I think the people writing it think it means something else, like some sort of intermission before the next thing they write, but I wouldn't include it in professional comms at all.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#7If I'm reading this correctly, extension developers want a way to read the user clipboard with a separate permission dialog than having to also request the ability to inject scripts into pages? If that is the case I can partially see why this is the way it is. The clipboard reading permission is part of the privacy controls built into the browser. So with page injection, the extension would have to request permission…
I came across this because I wanted to port an addon over to MV3. It simply used navigator.clipboard.writeText(). That by itself only works as a reaction to a user interaction (so not in bg scripts), unless you declare the "writeClipboard" permission in the manifest.
I don't know if there is a readClipboard permission as well.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#8I 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.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#9I 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 b…
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.
Re: Cannot read clipboard from service worker in a MV3 chrome extension (2020)
#10> Thanks for the issue.... > Thanks..... Aside: Do people know that trailing "..." tends to communicate annoyance or sarcasm? I think the people writing it think it means something else, like some sort of intermission before the next thing they write, but I wouldn't include it in professional comms at all.
My otherwise high-EQ boss does this all the time and it drives me bonkers.