1615717 - Give webpage info that a Linux middle click copy occurred from the OS

Status: UNCONFIRMED

(Core :: DOM: Events, enhancement)

Description

[lauradaquila]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36

Steps to reproduce:

Consider the following test case with all versions of Firefox on Linux:
data:text/html,<textarea id="foo">foo</textarea><textarea id="bar" placeholder="Select all in foo, then middle click here"></textarea><script>document.getElementById('foo').addEventListener('copy', () => window.alert('Received copy on source'));</script>

(1) Select foo in the first text area.

(2) Middle click into the empty text area next to the one containing foo.

Actual results:

The webpage does not get info that a middle click occurred.

Note that this existing behavior is the same in Chrome. I will be filing a feature request there too.

Expected results:

The webpage gets info that a middle click occurred from the OS. Could be via a old-fashioned copy event (a.k.a the test case), or could be surfaced via the Clipboard API.

Comment 1

[lauradaquila]

One update to the test case: FF needs user_pref('middlemouse.paste', true);

Comment 2

[Aaron Leventhal]

Link to Chrome bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=1052480

Comment 3

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
20200207195153

• Summary says paste but your testcase listens for the copy event.
• Testcase says to middle-click the second element, but the event listener is attached to the first.
• Listening for paste on middle-click was fixed in bug 1461708. I get the expected alert box if I set middlemouse.paste = true and middle-click the first element.

Comment 4

[lauradaquila]

developers don't receive a browser event for when the copy happens when the user uses middle click in Linux. Receiving a browser event that can be intercepted before the copy is complete would be very useful to have for us on the Google Docs developers' end.

Comment 5

[lauradaquila]

Apologies, please ignore my previous message, it was sent too soon.

I've updated the bug title to say "copy".

The intention is to middle-click on the second element. On Linux, this copies and pastes the content from the first element. The goal is for the first element to receive an event notifying it that its content was copied. At the moment it doesn't receive any event, although receiving it would be useful for web developers who might want to have their application react to content copying from it.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to lauradaquila from comment #5)

The intention is to middle-click on the second element. On Linux, this copies and pastes the content from the first element. The goal is for the first element to receive an event notifying it that its content was copied. At the moment it doesn't receive any event, although receiving it would be useful for web developers who might want to have their application react to content copying from it.

You are talking about selection buffer (I don't know the formal/common name of it), so, I feel odd to fire clipboard event at least with current interface because even after copy event is fired, global clipboard keeps its contents and it's available with Ctrl+v etc. So, I think that you should suggest new event to Clipboard API's WG.

Comment 7

[Darwin Huang]

(following up on comment #6)

The Clipboard API Specification where this issue could be filed is at https://github.com/w3c/clipboard-apis/issues/