Add methods to read from the clipboard in the WebExtension API

NEW
Unassigned

Status

()

Toolkit
WebExtensions: General
P3
enhancement
a month ago
15 days ago

People

(Reporter: robwu, Unassigned)

Tracking

57 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fix-optional)

Details

(Reporter)

Description

a month ago
We have tried to allow extensions to read/write from the clipboard by allowing extensions to use document.execCommand + paste/copy (like Chrome).
However, writing has always had some bugs and limitations, so we introduced the ability to write images in bug 1356543, and will support more types (text / html) in bug 1344410.

Bug 1312260 added support for clipboardRead, but the API is unusual (requiring a contenteditable element - bug 1340578): https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Interact_with_the_clipboard#Reading_from_the_clipboard (and even the documented example sometimes yields unexpected results - e.g. bug 1395951).

There is also a desire to remove a sync IPC message for clipboard data in bug 1375022. This would probably break the documented way to read from the clipboard.

To avoid these issues, the clipboard API from bug 1356543 should be extended with a method to read from the clipboard.

(a standard clipboard API is being developed, but it is far from ready - https://w3c.github.io/clipboard-apis/)
(In reply to Rob Wu [:robwu] from comment #0)
> Bug 1312260 added support for clipboardRead, but the API is unusual
> (requiring a contenteditable element - bug 1340578):

The fact that you need a contenteditable element to paste is a bug. I made it so that we always consider the copy and cut commands enabled in content documents a couple of years ago, and at the time we weren't exposing paste to any interesting targets.

I would be inclined to fix that problem and allow people to use document.execCommand('paste') if they have the clipboardRead permission from within webextensions.
(Reporter)

Comment 2

a month ago
(In reply to Michael Layzell [:mystor] from comment #1)
> (In reply to Rob Wu [:robwu] from comment #0)
> > Bug 1312260 added support for clipboardRead, but the API is unusual
> > (requiring a contenteditable element - bug 1340578):
> 
> The fact that you need a contenteditable element to paste is a bug. I made
> it so that we always consider the copy and cut commands enabled in content
> documents a couple of years ago, and at the time we weren't exposing paste
> to any interesting targets.

Can this bug be fixed easily?
 
> I would be inclined to fix that problem and allow people to use
> document.execCommand('paste') if they have the clipboardRead permission from
> within webextensions.

Is document.execCommand('paste') a stable API? Bug 1375022 suggests that it is not available to the web, and currently WebExtensions are the only consumer.
Flags: needinfo?(michael)
I've submitted a patch to bug 1340578.

(In reply to Rob Wu [:robwu] from comment #2)
> Is document.execCommand('paste') a stable API? Bug 1375022 suggests that it
> is not available to the web, and currently WebExtensions are the only
> consumer.

The unfortunate part about execCommand('paste') is that it is providing a synchronous API for an operation which is asynchronous on many platforms. Unfortunately I think that this is probably already locked in by the web platform, as if we receive a Ctrl-V keystroke we need to synchronously dispatch a paste event to the page already.

Given that, to my understanding (from bug 1340578), chrome is already exposing this API to extensions, we may as well follow suit.

ni? ehsan for his opinion.
Flags: needinfo?(michael) → needinfo?(ehsan)

Comment 4

a month ago
Well, extensions can have content scripts, which can call any function that is exposed to web content.  So yes, it does seem like our hands are tied here.  :-/  We should follow what Chrome does.  It would be nice if someone double checks to make sure that extensions in Chrome can execCommand('paste') successfully.  I'm assuming that is the case.
Flags: needinfo?(ehsan)

Updated

a month ago
Severity: normal → enhancement
status-firefox57: affected → fix-optional
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.