Closed Bug 1773681 Opened 4 years ago Closed 10 months ago

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)

task

Tracking

()

RESOLVED FIXED
147 Branch
Tracking Status
firefox147 --- fixed

People

(Reporter: mbrodesser, Assigned: edgar)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

No description provided.
Summary: Enable showing "Paste" button for `navigator.clipboard.readText()` when called from Addons → Enable showing "Paste" button for `navigator.clipboard.readText()` when called from Addons which don't have `clipboardRead` permssion

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!

Flags: needinfo?(tomica)

Hi Edgar! Personally, I would prefer 1 or 3, as my extension depends on that behavior to do some very cool things.

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.

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: nobody → echen

Move common code into head.js

Attachment #9299571 - Attachment description: Bug 1773681 - Cleanup clipboard browser tests; → Bug 1773681 - Cleanup clipboard browser tests; r?smaug
Attachment #9299572 - Attachment description: Bug 1773681 - Enable clipboard context menu on extension; → Bug 1773681 - Show clipboard context menu on extension; r?smaug
Blocks: 1619251
No longer blocks: 1770358
Flags: needinfo?(tomica)
Regressions: 2001749
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 147 Branch

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.

Flags: needinfo?(rbloor)

Added to my list

Flags: needinfo?(rbloor)

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?

Flags: needinfo?(echen)

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.

Flags: needinfo?(echen)
Flags: needinfo?(echen)

It looks good to me. Thanks!

Flags: needinfo?(echen)
QA Whiteboard: [qa-triage-done-c148/b147]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: