Enable showing "Paste" button for `navigator.clipboard.readText()` when called from Addons which don't have `clipboardRead` permssion
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | fixed |
People
(Reporter: mbrodesser, Assigned: edgar)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(2 files)
| Reporter | ||
Updated•4 years ago
|
| Assignee | ||
Comment 1•4 years ago
|
||
After bug 1744524, we use different security model for clipboard.readText() in web content which will show a prompt to user. Currently we keeps security model for Addons unchanged, i.e. Addon is allowed to read clipboard only if it has clipboardRead permission, otherwise, throw an error.
I am not sure if we need to apply the user prompt to Addon, there are following possible options off the top of my head.
1). Keeps security model for Addons unchanged: if Addon has clipboardRead permission, allow to read (without showing prompt), otherwise, throw an error.
2). If Addon has clipboardRead permission, show the prompt to user, otherwise reject promise.
3). If Addon has clipboardRead permission, allow read (without showing prompt), otherwise, show a prompt to user.
or 4). others
It will be nice to have some input from Addons folks, :zombie, would you mind shedding some light here? Or do you know who might have opinion on this? Thanks!
Hi Edgar! Personally, I would prefer 1 or 3, as my extension depends on that behavior to do some very cool things.
Comment 3•4 years ago
|
||
I think the option 3 would be our preference, generally whatever is available to normal web pages is by default exposed to extensions (unless we have a specific reason not to).
We would be very much against option 2, as it would be both a backwards-breaking change, and cross-browser compatibility issue.
I'll follow up with the team and let you know if we have any more opinions here.
| Assignee | ||
Comment 4•3 years ago
|
||
Thanks :zombie, then we will go with option 3 first in this bug, feel free to file a new bug or comment if any other opinions.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 5•3 years ago
|
||
Move common code into head.js
| Assignee | ||
Comment 6•3 years ago
|
||
Depends on D159895
Updated•3 years ago
|
Updated•3 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•10 months ago
|
Comment 8•10 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f8d8f9a96c74
https://hg.mozilla.org/mozilla-central/rev/bfde3f7d35a2
Comment 9•9 months ago
|
||
Richard, could you add an entry to the release notes for this? And double check if our existing documentation about clipboard usage is still accurate despite this change.
Comment 11•9 months ago
|
||
The Interact with the clipboard article indicates (as does the API documentation itself) that navigator.clipboard.readText() and navigator.clipboard.read() methods require the "clipboard-read" permission from the Web API Permissions API.
However, this bug refers to only the clipboardRead permission, which the documentation indicates is only applicable to document.execCommand("paste").
Should this bug be referring to the "clipboard-read" permission or does the clipboardRead permission now also provide permissions for the
navigator.clipboard read API methods?
| Assignee | ||
Comment 12•9 months ago
|
||
The clipboard-read permission no longer exists in the Web API Permissions API spec. The navigator.clipboard read methods use the security model that require user confirmation for each clipboard read access if the clipboard data is from different-origin.
The clipboardRead permission allows the use of navigator.clipboard read API methods without user confirmation.
This bug changes the behavior when that permission is not present. Previously, we rejected calls to the navigator.clipboard read APIs. Now, we fall back to showing a context menu to request user confirmation, matching the behavior of regular web pages.
Updated•9 months ago
|
Description
•