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

Steps to reproduce:

Usage of clipboard in Firefox running under Wayland (DE: GNOME Wayland) doesn't always work. The following bug usually is not present at the beginning, but after a while it starts happening, and working with Firefox becomes a bit annoying then.
Firefox: 75.0
OS: Arch Linux
What I do to reproduce the bug: Sometimes I copy text that is inside Firefox and try to paste it in another application.

Actual results:

I could not paste the text into any other window. What is weird, is that it is however possible to paste the copied text inside the same Firefox window.
By the way, it is possible to copy and paste text from other GTK or Qt programs (on Wayland). This seems to be a Firefox-specific bug, where Firefox seems to stop interacting with the GNOME clipboard at some point.
Closing and reopening Firefox does not always solve the issue. Sometimes I had to restart my PC to temporarily solve this problem, until it presents again.

Expected results:

Text copied from Firefox should have get pasted correctly in other applications.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Can you try to use wl-paste utility (from https://github.com/bugaevc/wl-clipboard or fedora ships wl-clipboard package) to verify clipboard state? Some gtk applications (like terminal) have issues to copy into.
Thanks.

I'm running 76.0b5 on Manjaro, Gnome Wayland. To be fair, I was attributing this bug to a few that are floating around in Gnome/Mutter since the 3.36.0 upgrade.

Resetting severity to default of --.

Since Friday I still have not experienced the reported behaviour. As soon as it happens again, I will use wl-paste and see what it print.

I am also hitting this bug. (Build rev 88449c910b64bf796522d2ad30de03b17b5ad4b6).

This is WAYLAND_DEBUG=1 wl-paste -n output. It hangs like previously reported.

(In reply to jacob.emery from comment #6)

Since Friday I still have not experienced the reported behaviour. As soon as it happens again, I will use wl-paste and see what it print.

The bug happened again, but I no longer think it is Firefox's fault. When copying from Firefox and pasting the content into Gtk apps, I noticed it works. However, when pasting into Telegram (run with Wayland backend), it does not always function, and most of the time restarting telegram solves the issue.
Since Telegram is the app I use most, I assumed it was working as expected.
In addition, wl-paste correctly prints in the Terminal the content copied from Firefox.

Just for information: there's a big bunch of Gnome/Mutter clipboard fixes that landed over the last week (one still pending). They cover both X11 and Wayland (and the translation between them) and will be released in 3.36.2 / 3.34.6 on April 25. - so there're good chances that some or even all of the cases you see will be fixed by that, feedback welcome :)

Update: to me this is definitely a Qt Wayland bug. In some Qt apps, the paste function stops working after a while. You can either restart the app, or you can simply wait for about a minute and the "paste" will work again. I have not experienced any problems with Gtk-based applications in the past month.

I am getting the exact same issue and I'm confident that this is not an issue with either GTK or Qt as i can reproduce this with wayland native lxterminal(libvte based), xwayland mate-terminal(libvte based), wayland native konsole(Qt based) and Xwayland simple terminal(Xlib based).

This happens in Sway too, with Codium and Firefox, Termite and Codium. It's been happening with increasing frequency on Nightly.

To reiterate, this bug affects XWayland and native Wayland clients, alike. It affects Qt and GTK clients. I'm testing right now with VSCodium (XWayland, GTK), Spectral (Qt5), Termite (GTK). Pasting from my Firefox stable build is broken.

I have to reboot Firefox stable, daily, for this bug.

Good. I'm hunting this bug too but without luck so far. Can you run Firefox with:

WAYLAND_DEBUG=1
MOZ_LOG="WidgetClipboard:5"

env variables and paste Firefox console output here when the clipboard fails? That would help to diagnose it.
Thanks.

Since I updated sway to 1.5.1 from 1.5.0, the issue surfaces much earlier. Before, I could have firefox running for hours without issue, now it happens very quickly. Not immediately, but after a few minutes. I have not analysed every changes, but I think there was a wlroot update in sway with this release.

The good side is that I might be able to get more debug logs. I will update this issue as soon as I have something relevant.

With WAYLAND_DEBUG=1, logs are a bit hard to follow. So I also looked without it (with only MOZ_LOG), and I get this:

### Here I hit ctrl+c
[Parent 3914573: Main Thread]: D/WidgetClipboard nsClipboard::SetData (clipboard)
[Parent 3914573: Main Thread]: D/WidgetClipboard     text targets
[Parent 3914573: Main Thread]: D/WidgetClipboard     gtk_target_table_new_from_list() = 0x7fc4bc01dd40
[Parent 3914573: Main Thread]: D/WidgetClipboard clipboard_clear_cb() callback
[Parent 3914573: Main Thread]: D/WidgetClipboard nsClipboard::SelectionClearEvent (clipboard)
[Parent 3914573: Main Thread]: D/WidgetClipboard     gtk_clipboard_set_with_data() is ok
[Parent 3914573: Main Thread]: D/WidgetClipboard data_device_selection() callback
[Parent 3914573: Main Thread]: D/WidgetClipboard data_device_data_offer() callback
[Parent 3914573: Main Thread]: D/WidgetClipboard data_device_selection() callback
### It hangs here when I do ctrl-v (or wl-paste) in another app (trying to paste doesn't log anything)
### the other app or wl-paste just hang indefinitely here, until I come back into firefox and copy again
### which logs the same as above, but un-hang the pasting app

Ok, I can now reproduce it 100%.

• Launch firefox
• Write "hello" in the empty address bar
• Hit ctrl+c
• Change to a xwayland app
• Hit ctrl+v
• Receiving app hangs
• Recopy from firefox to un-hang the receiving app

After those steps, copy-paste to wayland apps (and wl-paste), will also hang. Only cure is to restart firefox.

Thanks for the info! We have reports from all compositors about the clipboard stopping to work, so removing the "Gnome" from the title. Hope to get back to it soonish, as it's also my personal main pain point by now - but there's lots of big fish out there, so if someone wants to dive into this, please give it a go!

Hello. I did also do a log file. The header of the log contains the script that was executed to generate the log, and i did comment it manually afterwards for a better understanding what actions i took.

In brief:

• run WAYLAND_DEBUG=1 wl-paste --watch cat
• run MOZ_LOG=WidgetClipboard:5 firefox

actions i took:

• ctrl+c within selected address bar //NO output from wl-paste --watch
• ctrl+c from pasted and selected into/from search input field // Correct output from wl-paste --watch
• copy link location with context menu // NO output from wl-paste --watch
• mark text and copy with context menu // Correct output from wl-paste --watch
• mark text and copy with ctrl+c // Correct output from wl-paste --watch

by looking at the recorded log, i noticed some pattern:
When there is no output from wl-paste, nsClipboard::SetData is called twice, once with primary, once with clipboard and e.g. gtk_target_table_new_from_list() = 0x7f8f5e871200 have the same number,
instead of when there actually is correct output from wl-paste, the numbers after gtk_target_table_new_from_list() differ.

Attached the log resulting from bash copy-paste.log default-nightly-85.

NixOs version 21.03pre257989.f1f9a55fb4b
sway version 1.5-1dbb6990 (branch 'master')
Mozilla Firefox 85.0a1 20201214152913 built from mozilla-central changeset: 560428:8d6972b0b89b

For me the capability to copy any link via context menu or from address bar was gone since the release of 83.0.

Currently i suspect this could have been introduced by this mozilla-central changeset 551220:5c19f0bf1b11 but i do fail to build a version near that one to check if i am correct.

Thanks for the log, will look at it.

(In reply to chris from comment #23)

For me the capability to copy any link via context menu or from address bar was gone since the release of 83.0.

Currently i suspect this could have been introduced by this mozilla-central changeset 551220:5c19f0bf1b11 but i do fail to build a version near that one to check if i am correct.

You can use mozregression tool for it, run on terminal as:

MOZ_ENABLE_WAYLAND=1 mozregression --good 82.0 --bad 84

more info at:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool

(In reply to Martin Stránský [:stransky] from comment #25)

You can use mozregression tool for it, run on terminal as:
Thank you. Will have to see how this works out under NixOS, though.

Did it manually, right now. Because it seemed to be less trouble. Luckily i got a hit :)

This nightly lets me copy from address bar as well as links from context menu:
https://archive.mozilla.org/pub/firefox/nightly/2020/10/2020-10-02-09-25-36-mozilla-central/

The one directly after that one does not.
https://archive.mozilla.org/pub/firefox/nightly/2020/10/2020-10-02-15-43-27-mozilla-central/

So i am pretty confident it was introduced with the mozilla-central changeset 551220:5c19f0bf1b11 at least, this is one in between the relevant changes as of hg log --rev 2ce12e3e063c43c599ff6acb78be0d9bc038a862:c25899d7b631470b983650ee254177381a62eaad

Chris: hm, that's quite interesting, thanks for investigating. I'm pretty sure, however, that this would be a different bug - mind creating a new one for it?

Some notes already:

• a few commits after the version of sway 1.5-1dbb6990 (is that still up-to-date? Or did you update in between?), support for gtk-primary-selection was dropped (https://github.com/swaywm/sway/compare/1.5...master). So the commit in question should make sure primary selection still works on current sway master.
• I can't reproduce on Mutter and Weston, and I also tested the commit with gtk-primary-selection disabled in Mutter.
• I did a similar patch in gtk3 (and gtk4, but there I dropped gtk-primary-selection support altogether). Do you have any issues in other gtk apps, and which version do you use?

(In reply to chris from comment #21)

actions i took:

• ctrl+c within selected address bar //NO output from wl-paste --watch
• ctrl+c from pasted and selected into/from search input field // Correct output from wl-paste --watch
• copy link location with context menu // NO output from wl-paste --watch
• mark text and copy with context menu // Correct output from wl-paste --watch
• mark text and copy with ctrl+c // Correct output from wl-paste --watch

Chris,

I'm not able to identify from the log which action is success and which isn't. I expect what we need to see is actually missing from the log, perhaps we don't log that. Can you please try to catch the log and perform only one unsuccessful paste action from Firefox?

Also please run Firefox as:

WAYLAND_DEBUG=1 MOZ_LOG="WidgetClipboard:5, Widget:5" firefox

To get wayland and widget events.

Thanks.

@rmader
On your notes:

• i did an update yesterday evening and am now on sway 1.5-ba943c69. That is, one commit behind master right now.

• Firefox is the only application where i noticed that copying did stop working for links (through context menu) and address bar urls.
  But now that you mentioned it, it seems none of any different applications are able to share the primary clipboard (also tested between gtk3-demo and Firefox 83).
  I did not notice that behavior before, but it is easy to miss for me because mostly i work in alacritty terminal, and so i am used to copy & paste things to and from the outside terminal world

  Firefox is using GTK 3.24.23
  ldd /nix/store/v5n96yidylpdb02kwxc7b6r8ffi934jv-firefox-unwrapped-83.0/lib/firefox/libmozgtk.so | rg gtk
  libgtk-3.so.0 => /nix/store/48sa93c5qcg73n6clgcmciflrjlxl2a7-gtk+3-3.24.23/lib/libgtk-3.so.0 (0x00007f27a7826000)
  libgdk-3.so.0 => /nix/store/48sa93c5qcg73n6clgcmciflrjlxl2a7-gtk+3-3.24.23/lib/libgdk-3.so.0 (0x00007f27a772e000)

So it seems to be a sway related issue? Should i open a new issue here on bugzilla nevertheless, or is it useless then?

@stransky
In the log where i commented with (wl-paste bad) the following is failing, instead of where i commented (wl-paste good) the following succeeded.
Nevertheless, will do as you requested. Thank you.

(In reply to chris from comment #30)

Firefox is using GTK 3.24.23

This may be a hint: the gtk patches for the primary protocol landed in 3.24.24 (https://gitlab.gnome.org/GNOME/gtk/-/commit/de8329b3ce4b235eac9ddcbb6cd121cc83dd9e74). So updating gtk may resolve the issue.

So it seems to be a sway related issue? Should i open a new issue here on bugzilla nevertheless, or is it useless then?

Yes, please open one here. Especially if a gtk update solves the issue :/

Martin Stránský
attached the log of WAYLAND_DEBUG=1 MOZ_LOG="WidgetClipboard:5, Widget:5" build/bin/firefox -P default-nightly-85 --new-instance https://bugzilla.mozilla.org/show_bug.cgi?id=1631061 > copy-link-location.log 2>&1, where after starting up, i copied a link via context menu, switched to alacritty terminal and tried to paste into it.

(In reply to Robert Mader [:rmader] from comment #31)

This may be a hint: the gtk patches for the primary protocol landed in 3.24.24 (https://gitlab.gnome.org/GNOME/gtk/-/commit/de8329b3ce4b235eac9ddcbb6cd121cc83dd9e74). So updating gtk may resolve the issue.

Oh, gosh. That's some kind of rabbit hole :) Will see if i will get this managed here.

For reference, I opened this issue on GTK: https://gitlab.gnome.org/GNOME/gtk/-/issues/3367

Robert Mader
I can confirm: Firefox 85.0a1 built with gtk3 3.24.24 does not have the issue. There i am able to paste into terminal when copying from address bar or context menu copy link location. I guess this will be the same for FF83 and FF84.

(In reply to chris from comment #35)

Robert Mader
I can confirm: Firefox 85.0a1 built with gtk3 3.24.24 does not have the issue. There i am able to paste into terminal when copying from address bar or context menu copy link location. I guess this will be the same for FF83 and FF84.

Thanks for testing! Ok, ouch...I think I've tested that combination here (old gtk, new FF) - but maybe it only occurs in the combination with sway? Anyhow, I guess it's not really worth to investigate this much more - by the time we would release a workaround, most users will hopefully have updated their gtk version.

Back to the main topic of the clipboard failing randomly :)

(In reply to Robert Mader [:rmader] from comment #36)

Back to the main topic of the clipboard failing randomly :)
Thanks for taking time to clarify nevertheless.

(In reply to Christian Albrecht from comment #32)

Created attachment 9193719 [details]
copy-link-location.log (copy link via context menu and try to paste into terminal)

Martin Stránský
attached the log of WAYLAND_DEBUG=1 MOZ_LOG="WidgetClipboard:5, Widget:5" build/bin/firefox -P default-nightly-85 --new-instance https://bugzilla.mozilla.org/show_bug.cgi?id=1631061 > copy-link-location.log 2>&1, where after starting up, i copied a link via context menu, switched to alacritty terminal and tried to paste into it.

Thanks. From the log I see that Firefox sets clipboard data but there isn't any request fom compositor to get the data. Firefox sets these mime types:

[2034141.482] -> wl_data_source@89.offer("UTF8_STRING")
[2034141.495] -> wl_data_source@89.offer("COMPOUND_TEXT")
[2034141.508] -> wl_data_source@89.offer("TEXT")
[2034141.522] -> wl_data_source@89.offer("STRING")
[2034141.535] -> wl_data_source@89.offer("text/plain;charset=utf-8")
[2034141.547] -> wl_data_source@89.offer("text/plain")

It would help if you can use any clipboard manager and inspect clipboard content after paste from Firefox. What's actual clipboard content and if that content can be pasted.

For instance wl-paste --list-types gives me:

text/plain
text/plain;charset=utf-8
STRING
TEXT
COMPOUND_TEXT
UTF8_STRING

(In reply to Martin Stránský [:stransky] from comment #38)

It would help if you can use any clipboard manager and inspect clipboard content after paste from Firefox. What's actual clipboard content and if that content can be pasted.

Yes, i did that in my first attached log [1], kind of. There is no content that wl-paste is able to see if i understand it correctly.
This log was the combined output from MOZ_LOG=... firefox and WAYLAND_DEBUG=... wl-paste --watch cat, the later (if i understand it correctly) should output any content from clipboard as soon as it is filled with something new. Which does not happen in that cases.

[1] https://bugzilla.mozilla.org/attachment.cgi?id=9193212

This is the line in the second attachment [2], that gets repeated when i actually paste into terminal (but i did it only once for the log):
[2036379.002] wl_data_source@89.send("UTF8_STRING", fd 110)

[2] https://bugzilla.mozilla.org/attachment.cgi?id=9193719

The output of wl-paste --list-types after copy link via context menu is:

UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
SAVE_TARGETS

On the other hand, i have managed to be able to copy from address bar and link location via context menu again, after building with GTK 3.24.24. So maybe this is really something different, and i might not be helpful here.

This bug is caused by internal Firefox clipboard hack, when Firefox pastes it clipboard content instead of the content owned by compositor.

https://hg.mozilla.org/mozilla-central/rev/e8c18967320c

Cosmin, can we please backout the patch here? It causes a regression (Bug 1683989) and needs to be fixed differently.
Thanks.

:stransky , I`ve backed out e8c18967320c from autoland.
Backout link: https://hg.mozilla.org/integration/autoland/rev/bc1e625eef70ebb9b14ca6ea3dbab2127657d6f4

Thanks a lot!

Backout merged: https://hg.mozilla.org/mozilla-central/rev/bc1e625eef70

Slightly different behavior in my Nightly (86.0a1 (2020-12-22) (64-bit)): copy/paste WITHIN Firefox breaks as described. Copy from FF and paste into other wayland and xwayland apps works fine. Also copy from other apps and paste into FF. I see the problem specifically when copy/pasting within FF.

Thank you everyone for your continued work on this!

(In reply to campbell from comment #49)

Slightly different behavior in my Nightly (86.0a1 (2020-12-22) (64-bit)): copy/paste WITHIN Firefox breaks as described. Copy from FF and paste into other wayland and xwayland apps works fine. Also copy from other apps and paste into FF. I see the problem specifically when copy/pasting within FF.

Can you please try to catch that scenario on log? Run on terminal:

WAYLAND_DEBUG=1 MOZ_LOG="WidgetClipboard:5, Widget:5" ./firefox > log.txt 2>&1

and attach the log here.
Thanks.

I think we need bit more logging to clipboard content.

https://hg.mozilla.org/mozilla-central/rev/6b121d935c2c

Here's a log from before that commit got in, which I also posted to https://bugzilla.redhat.com/show_bug.cgi\?id\=1892680 . (I see you're also on that thread Martin).

I guess this is the right place for the canonical discussion of the bug, though.

NB I couldn't find this ticket the other night, so I created a bug specifically for the issue I'm seeing... whch may not be wha'ts described in this original bug report. I notice that my issue starts immediately, rather than "after a while".

potentially duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1688595 . Once we get more into the cause, we'll know if they're really duplicate or not.

Hold on please, there's another patch coming.
Thanks.

https://hg.mozilla.org/mozilla-central/rev/23701e398495

Guys, can you please retest clipboard with the latest nightly and attach a log if you see any issue?
Thanks.

Current version of Nightly 87.0a1 (2021-01-31) no longer has the (immediate) problem for me. Will post here later if the clipboard borks out after a time.

No longer a problem for me, either. Thanks.

Bug still present on normal release Firefox 87.0 (64-bit) for Arch Linux.c

See Bug 1703763 - that one should fix all Wayland clipboard bugs.

Yes, it's fixed in 89.0 by Bug 1703763.

Bug is still present on 89.0 :(

Is FF supposed to be run with MOZ_ENABLE_WAYLAND for this to work?

(Sorry, nevermind, it was already set)

This bug still appears for me on Firefox 89, under Sway 1.6 on Fedora. When launched, the bug doesn't immediately appear, but a reliable way to trigger it seems to be to drag and drop a tab outside the Firefox window to cause it to open in a new window on a different monitor. After doing this, pasting text from Firefox into another app will cause the app to hang.

I have tried this with VS Code (under XWayland), which becomes responsive again a few seconds after pasting into it, though nothing is pasted, and Alacritty (Wayland-native), which hangs until something else is copied, replacing the contents of the clipboard which was attempted to be pasted.

The attached log was recorded when copying and pasting before dragging out a tab - which works - and then dragging out a tab to create a new window, then c&p again which manifests the bug. I've added lines prefixed with *** note: indicating approximately when these actions were performed.

I also have this bug with same behavior as above with Nightly 90.0a1 on Sway 1.51 on Ubuntu 21.04.

If you still see it please open a new bug for it. Also please test a different compositor like Mutter to verify it's a general bug and not Sway related one. Thanks.

I'm observing the same problem in 89.0.1 in Mutter.

I don't understand why we need a new ticket. This ticket is simply in the wrong status since the bug was not actually fixed.

(In reply to Drew from comment #79)

I'm observing the same problem in 89.0.1 in Mutter.

I don't understand why we need a new ticket. This ticket is simply in the wrong status since the bug was not actually fixed.

Can confirm it is still an issue on 89.0.2 under default Fedora 34 workstation. It appears after a couple of days of not restarting Firefox.

(In reply to Drew from comment #79)

I'm observing the same problem in 89.0.1 in Mutter.

I don't understand why we need a new ticket. This ticket is simply in the wrong status since the bug was not actually fixed.

Because the bug may have a different cause and needs a different fix, I need more logs and info.
We generally don't re-use already closed bugs with patches as it causes confusions.
So please open a new ticket for it and post bug ID here.
Thanks.

New bug page: https://bugzilla.mozilla.org/show_bug.cgi?id=1722369

ID: 1722369