1756497 - In-page clipboard copies are only sent to XA_CLIPBOARD and not XA_PRIMARY as well

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect, P3)

Description

[garethpulham]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

In Firefox 91.5.0esr on Linux (Debian) Open two tabs:

• A new, empty tab
• A page with in-page copy to clipboard function (eg: https://github.com/mozilla/firefox-translations )

In the new tab, type "abc" into the url bar, then highlight and cut/copy it.

In a terminal, observe the clipboard state:
xclip -selection primary -o -> abc
xclip -selection clipboard -o -> abc

Now, go to the tab with in-page clipboard push, for example a github project homepage.
Click the green "Code" button, and then the copy icon next to the url in the modal presented.

Return to the terminal and observe the clipboard states:
xclip -selection primary -o -> abc
xclip -selection clipboard -o -> [e-mail]:mozilla/firefox-translations.git

Then highlight some content on a page, and observe the clipboard status:
xclip -selection primary -o -> webextension
xclip -selection clipboard -o -> [e-mail]:mozilla/firefox-translations.git

Then paste into the url bar, and cut from the result, observe that the primary and clipboard elements are synced.

Actual results:

At different stages, XA_PRIMARY and XA_CLIPBOARD fall out of state. Specifically:
Ctrl+C puts the selection into both buffers
in-page copies only go to XA_CLIPBOARD
content selection only goes to XA_PRIMARY

Expected results:

All methods of copy/cutting content should fill both buffers, ensuring sync at all times.
Putting content in different buffers leads to the same logical action ("copying some text") to have different effects depending on how the action was completed.
Notably, some external applications you may wish to paste to will only read one buffer or the other, meaning the user may have to re-sync the paste buffers themselves after receiving an "out of date" paste.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Sync' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Ben Dean-Kawamura [:bdk]]

Thanks for the report, but I think I'm missing something here.

in-page copies only go to XA_CLIPBOARD
content selection only goes to XA_PRIMARY

I thought this is how the clipboard works in general. PRIMARY holds the current selection, while CLIPBOARD holds the last copied text.

Are you mostly concern with the use case when github or some other site copies to the clipboard from Javascript? In that case I think there's a case to be made for copying to both clipboards. But I don't think the two clipboards should always be kept in sync -- otherwise what's the point of having 2?

Comment 3

[garethpulham]

(In reply to Ben Dean-Kawamura from comment #2)

I thought this is how the clipboard works in general. PRIMARY holds the current selection, while CLIPBOARD holds the last copied text.
Are you mostly concern with the use case when github or some other site copies to the clipboard from Javascript? In that case I think there's a case to be made for copying to both clipboards. But I don't think the two clipboards should always be kept in sync -- otherwise what's the point of having 2?

I don't think it's a reasonable expectation for users for copying to only sometimes work.
I'm not particularly worried about the third case (selection being pastable - hitting Ctrl+C is easy there) but I do think that a page saying that something has been copied should put it into both.

For example, on github, crates.io, etc, the current workaround is to hit the copy button, open a new tab, paste into the url bar, then cut from the url bar. If you don't do this, then you cannot paste into a number of terminal emulators.

Comment 4

[Ben Dean-Kawamura [:bdk]]

Can we summarize the issue as "On Linux, when Javascript copies to the clipboard, Firefox should save the data to both the PRIMARY and CLIPBOARD selections?" That seems pretty reasonable to me and I think it fixes your use case.

For what it's worth, I think the best workaround on github is to select the text rather than hit the copy button. That way you can paste with the middle button into a terminal emulator. This isn't ideal but it's better than having to paste into a new window.

Comment 5

[garethpulham]

(In reply to Ben Dean-Kawamura from comment #4)

Can we summarize the issue as "On Linux, when Javascript copies to the clipboard, Firefox should save the data to both the PRIMARY and CLIPBOARD selections?" That seems pretty reasonable to me and I think it fixes your use case.
That'd probably be the minimum, sure. I think we're just making the problem smaller than fixing it, but that's progress.

For what it's worth, I think the best workaround on github is to select the text rather than hit the copy button. That way you can paste with the middle button into a terminal emulator. This isn't ideal but it's better than having to paste into a new window.
This is fine for github, but there are places like crates.io where it's not possible to select the text, they have overridden the click events on the appropriate section such that it's not possible to select and copy the text. Eg. https://crates.io/crates/rand
This is definitely an accessibility bug with them, but it doesn't make inconsistent copy behaviour less of an issue on firefox.

This same issue is not exhibited in other browsers, which I suspect is why there are many websites that expose this.

Comment 6

[garethpulham]

I broke the formatting on the lat comment, but the salient bits are:

• That summary would probably be the minimum, sure. I think we're just making the problem smaller than fixing it, but that's progress.
• That workaround is fine for github, but there are places like crates.io where it's not possible to select the text, they have overridden the click events on the appropriate section such that it's not possible to select and copy the text. Eg. https://crates.io/crates/rand . This is definitely an accessibility bug with them, but it doesn't make inconsistent copy behaviour less of an issue on firefox.
• This same issue is not exhibited in other browsers, which I suspect is why there are many websites that expose this.