[Firefox] Paste into message box with dom.event.clipboardevents.enabled=false fails
Closed this issue · 7 comments
Steps to reproduce
- Set
dom.event.clipboardevents.enabled=falseinabout:config. - Attempt to paste anything into the message box.
Resetting dom.event.clipboardevents.enabled to true resolves the issue, but I disable cliboard events because some websites block pasting and disabling the events generally fixes the issue. Honestly this is the first time that I've seen a website where disabling clipboard events breaks pasting -- I wasn't even aware that was possible 😅.
This broke fairly recently, though I'm not sure if it was the latest update or a previous one.
Outcome
What did you expect?
Paste should work.
What happened instead?
It doesn't.
Operating system
openSUSE Tumbleweed (Linux)
Browser information
Firefox 113.0.2
URL for webapp
app.element.io
Application version
Element version 1.11.32, Olm version 3.2.14
Homeserver
cyphar.com (synapse 1.85.1)
Will you send logs?
No
That setting is non-standard and not even documented in its full extent of effects to my knowledge on MDN. Element handles pasting itself for multiple reasons
- It uses a contenteditable div which it needs to prevent you pasting things it doesn't support into, e.g. rainbow marquees, etc
- allowing you to paste files for upload
- allowing you to copy&paste pills and other rich content that isn't text or HTML between rooms
- handling the pasting of other entities like Safari's Insert from Phone which inserts a blob image
Given this is a non-standard feature I doubt any effort will be seen here to resolve it unless it comes from the community.
In that case, is it possible to give some kind of warning to the user as opposed to failing silently? (It kind of sucks you can't enable it per-site...)
From the name dom.event.clipboardevents.enabled it sounds like the app simply won't receive the onPaste event, so not entirely sure how it could even detect it?
Related pyllyukko/user.js#287 - apparently it affects Google Docs too
Okay, I'll close this in that case. At least next time someone searches dom.event.clipboardevents.enabled in this repo, they'll be able to see that this is not supported (and with good reason).
That setting is non-standard and not even documented in its full extent of effects to my knowledge on MDN. Element handles pasting itself for multiple reasons
The whole clipboard API isn't really a standard: "This feature is not Baseline because it does not work in some of the most widely-used browsers.".
The current specification is a draft, and has the following statements in 5.3.2.:
Event handlers may read data from the system clipboard if either of the following is true
Notice the usage of may, which indicates a possibility, not a cold hard truth. Moreover, having the user refuse clipboard manipulation/access/… is perfectly specified and accepted:
For the paste action, the script-may-access-clipboard flag depends on an implementation-specific permission mechanism for determining what sites or apps may read from the clipboard. When a paste action is triggered by a script, the implementation must not make clipboard contents available without the user’s permission.
Even though the Clipboard Event API is not covered by the Clipboard permission, user agents may choose to provide a method for the user to disable this API or to configure which sites are allowed to access it.
The whole clipboard API isn't really a standard: "This feature is not Baseline because it does not work in some of the most widely-used browsers.".
Sure, but we're not relying on that, but rather on the paste event which has full compatibility. https://developer.mozilla.org/en-US/docs/Web/API/Element/paste_event#browser_compatibility
user agents may choose to provide a method for the user to disable this API or to configure which sites are allowed to access it.
The fact there's no signal to detect this to inform the user why its failing is not ideal.