I know there are a lot of valid complaints about Manifest v3, but I don't understand this one. You're telling me that browser extensions should be able to read and write to my clipboard silently at all times, with no user activation or notification? Honestly, that's kind of horrifying, and I'm shocked to hear it existed on v2 extensions. It sounds like a great way to build a keylogger for user passwords.<p>What are some valid usecases for this permission? I guess "syncing clipboards between two operating systems" is one of them? But why build that as a browser extension? It seems like the wrong tool for the job.
I think Chrome's reasoning for this is completely fair:<p>> <i>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><p>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.
Does 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?<p>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.<p>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.
If 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?
My company had a chrome extension they used for making twilio phone calls. V3's service worker focus made that a complete nonstarter. Ended up writing a thing to make phone calls in a background tab, use the Broadcast channel Api to communicate between the background tab and the active tab, and wrote instructions on the background tab for allowing sound permissions explicitly. The plus side is that we likely won't be dependent on chrome anymore, but I expect I'm not at the only company who got a rude awakening from the v3 transition. And yes, you can use v2 extensions with chrome enterprise, which I have no interest in doing.
Hi, Simeon from the Chrome Extensions team here. Clipboard access is one of the browser capabilities that currently requires a document to use. We're planning to address this use case (and others that require DOM) by introducing a new capability called offscreen documents[1].<p>In short, an offscreen document is a temporary headless page that is instantiated for a given reason that requires DOM access. It <i>is not</i> meant as a long-lived background context.<p>[1]: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1339382" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=133938...</a>
What I think is that what should be needing for browser extensions is to be able to write extensions in C, and available only for manual install by advanced users (so that it is not available to the official catalog of extensions).<p>However, additional capabilities to interact with the browser are also needed, including to implement new and intercept existing: protocols, MIME types, character encodings, HTML commands, CSS commands, JavaScripts in web pages (and the API they have access to), ARIA, menus, user interface elements, etc. (I think things will need to be rewritten to make this work efficiently, including moving many features to extensions which are then included by default, instead of being core features.)<p>Making C APIs for purposes would be helpful, although even if the existing API are with JavaScripts, JavaScript functions can be accessed by C codes by implementing N-API, I suppose.
> Thanks for the issue....<p>> Thanks.....<p>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.
This bug hasn't received a comment from another @chromium.org in >1 yr. Feels like so many of Google's bugs related to functionality many users relied on
It's extremely frustrating how some chrome extension apis such as chrome.tabCapture simply are no longer background context compatible, since they aren't in service workers. And they're just completely silent, don't even acknowledge the shortcomings. Just a hugely frustrating developer experience. Shame on Google, and this whole MV3 fiasco has permanently soured my view on Chrome developer Relations.