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

Steps to reproduce:

Leave Firefox open for 30, 60, 90 minutes in Wayland/Sway environment. Try to copy text and paste in another app, such as Slack or vim.

Actual results:

Other app freezes for about a minute, apparently waiting for some kind of clipboard contents request to complete. I die a little bit inside.

Expected results:

It should paste the text.

Note that "30, 60, 90" minutes just meant to mean "a while".

https://bugzilla.mozilla.org/show_bug.cgi?id=1631061 This bug previously was thought to address this issue but did not resolve it for several users.

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

Having the same issue here on Ubuntu 21.04 with gnome. Only solution for me is to restart firefox completely which interrupts my workflow completely

I also have this issue om Manjaro with KDE + Wayland. Copy from one firefox window to another works.
Copy from firefox to another application hangs the application
Copy from another application to firefox pastes one empty character.

The current workaround is closing your browser and restore last session to copy the content anyway.

Can you please test latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries

and run Firefox with:

MOZ_LOG="WidgetClipboard:5"

env variable on terminal. It should produce lock from clipboard events. Please attach the log here from the time when you see the issues.

Thanks.

I was able to reproduce it immediately: open nightly, duplicate tab, move the tab with the mouse out of the window to create a new window.
Copy one thing from window 1 to window 2: no issue.
Try to paste the same text in a texteditor and nothing happens and the application in questions hangs.

A video showcasing the issue is available here: https://youtu.be/cRkwl0vkUT8

Good, will look at it, Thanks.

A patch from Bug 1722700 seems to help a bit here so let's wait until it lands.

Also can you please re-test under nested mutter compositor? How-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_different_Wayland_compositor
Thanks.

The patch in bug 1722700 seems to only change drag-and-drop stuff. This bug is not about drag-and-drop.

(In reply to Teoh Han Hui from comment #13)

The patch in bug 1722700 seems to only change drag-and-drop stuff. This bug is not about drag-and-drop.

On Wayland they are closely interlinked. If the DnD code somehow gets "stuck", it may well break copy-paste. Comment 8 also mentions it as part of the STR.

Please try to re-test under mutter as I can't reproduce it there.
Thanks.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #15)

Please try to re-test under mutter as I can't reproduce it there.
Thanks.

When I run mutter mutter --wayland --nested and I run WAYLAND_DIPLAY=wayland-1 MOZ_ENABLE_WAYLAND=1 firefox-nightly it still opens in kwin. I have tries wayland-0 and 2 as well without result

Thanks for testing. When you run mutter in tested mode, it prints wayland diplay on terminal, in my case it's:

mutter-Message: 13:11:45.346: Using Wayland display name 'wayland-1'

can you check that?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

Thanks for testing. When you run mutter in tested mode, it prints wayland diplay on terminal, in my case it's:

mutter-Message: 13:11:45.346: Using Wayland display name 'wayland-1'

can you check that?

It is showing wayland-2, I used that but the nightly window still opens outside of the mutter window. Is that expected behaviour or should it open inside the mutter window?

(In reply to Fraise from comment #18)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

Thanks for testing. When you run mutter in tested mode, it prints wayland diplay on terminal, in my case it's:

mutter-Message: 13:11:45.346: Using Wayland display name 'wayland-1'

can you check that?

It is showing wayland-2, I used that but the nightly window still opens outside of the mutter window. Is that expected behaviour or should it open inside the mutter window?

Sorry, there's a typo in the instructions I posted, correct Wayland display variable is WAYLAND_DISPLAY so run as:

WAYLAND_DISPLAY=wayland-2 MOZ_ENABLE_WAYLAND=1

I did (In reply to Martin Stránský [:stransky] (ni? me) from comment #19)

(In reply to Fraise from comment #18)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #17)

Thanks for testing. When you run mutter in tested mode, it prints wayland diplay on terminal, in my case it's:

mutter-Message: 13:11:45.346: Using Wayland display name 'wayland-1'

can you check that?

It is showing wayland-2, I used that but the nightly window still opens outside of the mutter window. Is that expected behaviour or should it open inside the mutter window?

Sorry, there's a typo in the instructions I posted, correct Wayland display variable is WAYLAND_DISPLAY so run as:

WAYLAND_DISPLAY=wayland-2 MOZ_ENABLE_WAYLAND=1

Yes I saw that as well, otherwise it does not run. But still that does not seem to open the window inside the mutter session.

Hm, no idea why it's ignored then.

Having same issue here on Manjaro Kde (Wayland) 90.0.2 (Stable)

Not sure if it's the same bug, but I'm running 91.0b9 on KDE(wayland) and clipboard produces empty content in the system clipboard if I copy from the address bar. However it's possible to copy from the address bar to the search bar and then if I copy from the search bar the system clipboard is not empty anymore.
Any other place I copy from works just as expected.

Can you try latest nightly with async clipboard enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1725149#c5)?
Thanks.

Tried with nightly 2021-08-13 and widget.wayland.async-clipboard.enabled set to true but no changes, when I copy from the address bar it's shows empty clipboard.

Testing now, could be a while till the bug triggers.

For me it takes usually 5-10 minutes for it to trigger

Here are the logs from the whole browser session where the bug (Firefox -> other window copy and paste) emerges. Last hundred or so lines (has some extra newlines in between) are from trying to copy the other way (default clipboard via pbcopy to Firefox).

Thanks for the log, this seems to be relevant:

[Parent 11025: Main Thread]: D/WidgetClipboard nsRetrievalContextWaylandAsync::ReleaseClipboardData [7efe580c1810]
[Parent 11025: Main Thread]: D/WidgetClipboard nsClipboard::HasDataMatchingFlavors (primary)
[Parent 11025: Main Thread]: D/WidgetClipboard nsRetrievalContextWaylandAsync::GetTargets()
[Parent 11025: Main Thread]: D/WidgetClipboard doing iteration...
[Parent 11025: Main Thread]: D/WidgetClipboard wayland_clipboard_contents_received() selection_data = 7ffe4b034d90
[Parent 11025: Main Thread]: D/WidgetClipboard nsRetrievalContextWaylandAsync::TransferAsyncClipboardData(), aSelectionData = 7ffe4b034d90
[Parent 11025: Main Thread]: D/WidgetClipboard request number matches
[Parent 11025: Main Thread]: D/WidgetClipboard no targes at clipboard (null)
[Parent 11025: Main Thread]: D/WidgetClipboard nsClipboard::HasDataMatchingFlavors (primary)
[Parent 11025: Main Thread]: D/WidgetClipboard nsRetrievalContextWaylandAsync::GetTargets()
[Parent 11025: Main Thread]: D/WidgetClipboard nsRetrievalContextWaylandAsync is already used!
[Parent 11025: Main Thread]: D/WidgetClipboard no targes at clipboard (null)

The malfunction after while should be fixed by Bug 1727268.

Setting clipboard.plainTextOnly to true and clipboard.autocopy to false seem to fix the problem for me. I presume that the first config is what matters, but I'm not completely sure.

@crazytec86
"Setting clipboard.plainTextOnly to true and clipboard.autocopy to false seem to fix the problem for me. "

FYI, not for me. Firefox 90.0.2 64 bit Ubuntu 21.04

(In reply to Martin Stránský [:stransky] (ni? me) from comment #31)

The malfunction after while should be fixed by Bug 1727268.

If I see correctly this is fixed in the 93 branch, should we able to test this with the 93.0a1 nightly?

The bug I produced above with the duplicate tab and moving it to a new window and then trying copy paste is still there for me on the latest nightly 93.0a1.

Please try the clipboard again with widget.wayland.async-clipboard.enabled set to true at about:config.
Thanks.

EDIT: Test on latest nightly from Sep 1 please.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #36)

Please try the clipboard again with widget.wayland.async-clipboard.enabled set to true at about:config.
EDIT: Test on latest nightly from Sep 1 please.

It worked for me! Copy still functional after 30mn.
On nightly, 93.0a1 (2021-09-01) (64-bit) via the current Ubuntu PPA.

It tried Fraise case (duplicate tab + move to new window), it also worked.

I tried my case and I am still unable to paste into another application which is not firefox after duplicating my screen.

So

1. open new nightly instance
2. enable widget.wayland.async-clipboard.enabled
3. close nightly
4. open nightly
5. duplicate recommended tab
6. drag the duplicate tab to another space so it creates a new firefox instance
7. copy from instance 1 to instance 2: works
8. try to paste the same text into a text editor or terminal: fails.

I'm affected with this bug right after detach a tab, which opens a new window/instance. Before that the clipboard was working well.

The clipboard is working inside Firefox, coping and pasting from/to tabs or instances. But it doesn't work to copy or paste from/to any other app.

The clipboard outside Firefox is working well, between LibreOffice, gedit, terminal and others.

This is Ubuntu 21.04 + Firefox 91.0.2 (64-bit)

Okay, thanks for the report.

I'm not sure I completely understand what's going on here and I can't reproduce it, can you please create a creencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Collect_information_for_a_bug_report

Also make sure you use latest nightly, not Firefox 91.
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries

Thanks.

Well, this is weird.

I was having 8 tabs (usually I have lot of tabs opened) and was able to reproduce the issue 2 times, when detaching a tab with a Vimeo video. To restore the clipboard to work I have to restart Firefox.

When I was ready to do a screencast, I close the tabs to left just 2 opened: this page 2 times. Then I've detached one tab and the clipboard was still working. Then I closed the detached tab and added a new tab with the same video. Detached the tab and the clipboard is still working.

Then restarted Firefox and restored the previous 8 tabs. After detaching the same video, the clipboard is still working. I've restarted Firefox a couple of times more and repeated the process, but now I'm unable to reproduce the bug.

Sorry for that. I will back if I can reproduce the issue again.

--- PS ---
Something strange happens at the time to detach this video. Normally I can drop the tab a little outside the main window and the tab is detached.

But in this case I have to move far away the main Firefox window to have it detached. In fact, I've moved the Firefox window a little down to make room to move the tab up and far from it.

I'm almost sure that it has nothing to do with this issue, but this was something different.

Upgrading to the v93 beta from snapcraft fixed this bug for me (even with widget.wayland.async-clipboard.enabled set to false).
I'm on Ubuntu 21.04 and can reproduce the bug 100% of the time in Firefox 92.

Sorry for taking such a long time, but apparently screencasting from wayland is quite difficult to setup. Anyway here is a screen cast of the exact bug I'm experiencing: https://gfycat.com/ficklecloudyankolewatusi You can see how copying from the address bar yields empty result in system clipboard but copying from search bar actually fills the system clipboard with the text I copied.

I'm currently running Firefox 93b8 and every now and then I'm also trying nightly, but the behavior is exactly the same. Compared to the other posters I can reproduce this bug 100% of the time, no need to detach tab.

Not sure why the title was changed, simply detaching a tab does not produce the bug for me (the author of the bug).

The bug takes several hours to emerge and I don't know what steps are required to reproduce it. I simply know clipboard starts halting other apps after a few hours of use and have provided logs. I am also not capable of using nightly, I do have to actually use my browser for my day-to-day work, I've gone to some lengths as an end user already just to highlight this major bug.

Sure, not a problem.

So should I make another bug report about the clipboard stop working?

Please apply the following patch on GTK and check if the issue is still present: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4045

Note: the merge request above is superseded by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4058

(In reply to msizanoen from comment #49)

Note: the merge request above is superseded by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4058

Success! After applying this patch and rebuilding gtk everything started working, I can copy paste from my address bar

Closed as moving, Thanks.

seems like stable snap package of Firefox is still not updated so the bug is still there.

My original bug seems to be resolved for 2-4 months before FF v95 (I lost track).