[Sway] firefox with wayland hangs on clipboard with mime-type TEXT
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: todd.freed, Unassigned, NeedInfo)
References
(Blocks 2 open bugs)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
I am using firefox on arch linux with wayland and sway.
About Firefox
92.0 (64-bit)
Mozilla Firefox for Arch Linux
archlinux - 1.0
I am running a wayland clipboard client program to print changes to the state of the wayland primary clipboard. While I am running this program, I use the mouse to select a block of text in firefox.
with WAYLAND_DEBUG=1 firefox, these are the logs I see,
[3918654.967] zwp_primary_selection_device_v1@28.data_offer(new id zwp_primary_selection_offer_v1@1231095616)
[3918654.977] zwp_primary_selection_offer_v1@4278190083.offer("text/html")
[3918654.983] zwp_primary_selection_offer_v1@4278190083.offer("text/_moz_htmlcontext")
[3918654.992] zwp_primary_selection_offer_v1@4278190083.offer("text/_moz_htmlinfo")
[3918654.997] zwp_primary_selection_offer_v1@4278190083.offer("UTF8_STRING")
[3918655.003] zwp_primary_selection_offer_v1@4278190083.offer("COMPOUND_TEXT")
[3918655.010] zwp_primary_selection_offer_v1@4278190083.offer("TEXT")
[3918655.017] zwp_primary_selection_offer_v1@4278190083.offer("STRING")
[3918655.023] zwp_primary_selection_offer_v1@4278190083.offer("text/plain;charset=utf-8")
[3918655.032] zwp_primary_selection_offer_v1@4278190083.offer("text/plain")
[3918655.038] zwp_primary_selection_offer_v1@4278190083.offer("text/x-moz-url-priv")
[3918655.048] zwp_primary_selection_device_v1@28.selection(zwp_primary_selection_offer_v1@4278190083)
[3918655.297] zwp_primary_selection_source_v1@82.send("TEXT", fd 160)
Note that firefox is offering to vend the selected content via several different mime-types (text/html, text/_moz_htmlcontent, UTF8_STRING, etc).
Actual results:
In my client, if I accept the offered content as mime-type TEXT, then firefox does not write any data to the file descriptor (160 in this example), and it hangs. This is the debug snippet above. The UI is from then on completely unresponsive (music that firefox is playing continues to play, fwiw). It's necessary to kill the process and restart it.
If I accept the offered content as mime-type text/plain;charset=utf-8, then everything works fine.
Expected results:
Firefox should be prepared to vend selected content with every mime-type that it advertises. If it doesn't want to vend as TEXT that's ok, just don't advertise TEXT.
It seems like there's a mismatch in the code to generate the list of mime-types for offers, and the code to vend the actual data in the chosen mime-type.
|
||
Comment 1•4 years ago
|
||
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.
|
||
Comment 2•4 years ago
|
||
Can you please test latest nightly with clean profile? It uses async clipboard there:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.
|
||
Comment 3•4 years ago
|
||
I've been working on a clipboard monitor/manager (clipmon) for wayland, and I'm coming across [apparently] this issue.
When my tool starts up, it tries to read any content from the clipboard and take ownership itself. I frequently notice that Firefox fails to send data to it tho.
When normal applications paste, they only request one mime-type. I request all of them (I admit there's room for improvement on my end, but that's beyond the point).
clipmon does request the selection data (from Firefox in this case):
[2069981.729] -> zwlr_data_control_offer_v1@4278190080.receive("text/plain", fd 11)
[2069981.756] -> zwlr_data_control_offer_v1@4278190080.receive("UTF8_STRING", fd 13)
[2069981.778] -> zwlr_data_control_offer_v1@4278190080.receive("TEXT", fd 15)
[2069981.795] -> zwlr_data_control_offer_v1@4278190080.receive("COMPOUND_TEXT", fd 17)
[2069981.813] -> zwlr_data_control_offer_v1@4278190080.receive("STRING", fd 19)
[2069981.830] -> zwlr_data_control_offer_v1@4278190080.receive("text/plain;charset=utf-8", fd 21)
And firefox does get the request:
[2069139.748] zwp_primary_selection_source_v1@75.send("UTF8_STRING", fd 157)
[2069981.994] zwp_primary_selection_source_v1@75.send("text/plain", fd 158)
[2069982.046] zwp_primary_selection_source_v1@75.send("UTF8_STRING", fd 159)
[2069982.065] zwp_primary_selection_source_v1@75.send("TEXT", fd 160)
[2069982.079] zwp_primary_selection_source_v1@75.send("COMPOUND_TEXT", fd 161)
[2069982.091] zwp_primary_selection_source_v1@75.send("STRING", fd 162)
[2069982.105] zwp_primary_selection_source_v1@75.send("text/plain;charset=utf-8", fd 163)
But, based on the logs on my tool, it's never getting any data on any of the pipes.
Additionally, it's clear that Firefox leaks file descriptors; each time that I re-run clipmon, Firefox logs the .send events with higher fd numbers. I quickly reached 300, and if you have the patience I'm sure Firefox eventually dies due to running out of file descriptors.
Reproduction steps
You can use my work-in-progress clipboard manager to reproduce this: https://sr.ht/~whynothugo/clipmon/
Commit 9caf34a1cf4bdd4fe98e67d48071c13bcaeb615c works for reproducing.
- Clear both clipboards. I'd suggest opening some application, copying to both, and closing that application.
- Open Firefox:
WAYLAND_DEBUG=1 firefox -P tmp - Type something in the URL bar and select it (so it's copied to PRIMARY)
- Run clipmon:
WAYLAND_DEBUG=1 cargo run
You'll notice that clipmon sends requests for all the mime-types Firefox is publishing, but only gets responses for a few.
You can Ctrl+C clipmon to kill it. If you re-run it, you'll notice that the same happens, but the fd numbers on Firefox's logs have increased. If you run it over and over, you can see that fd numbers just keep increasing, indicating an fd-leak somewhere.
Make sure you kill clipmon once you're done exploring -- unless you want to crash your main Firefox session!
|
|
||
Comment 4•4 years ago
|
||
Is that still true with Firefox 94 which uses Gtk clipboard?
|
Reporter | |
Comment 5•4 years ago
|
||
Yes, the issue is still present in Firefox 94. If I accept the offer with mime type "TEXT", firefox hangs.
|
|
||
Comment 6•4 years ago
|
||
(In reply to todd.freed@gmail.com from comment #5)
Yes, the issue is still present in Firefox 94. If I accept the offer with mime type "TEXT", firefox hangs.
Can you try that with new profile? We use Gtk clipboard now and Firefox should behave as well as other Gtk applications - gedit for instance.
|
|
Reporter | |
Comment 7•4 years ago
|
||
I think you should have someone at Mozilla reproduce the problem. The steps here are quite clear IMO.
|
|
||
Comment 8•4 years ago
|
||
Uhm, it's still broken, but symptoms have somewhat changed:
- When another app copies from all the selections, the it reads 0 bytes in most pipes.
- When a third application tries to paste (while Firefox own, that application Freezes.
From the point on, any other application will crash if pasting while Firefox owns the clipboard. The clipboard continues working fine when other apps copy things, and restarting Firefox fixes it, so it seems that Firefox's clipboard is ending up in a "poisoned" state.
The same code linked above helps repro the issue.
|
|
||
Comment 9•4 years ago
|
||
For what it's worth, none of UTF8_STRING, TEXT, COMPOUND_TEXT or STRING are actually valid mime-types; they're more of a historical X11 thing, so the best fix here would be for Firefox to stop offering these invalid types altogether.
|
|
||
Updated•4 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Updated•1 year ago
|
|
|
||
Comment 11•1 year ago
|
||
I followed the reproduction steps above and the issue no longer reproduces for me.
|
|
||
Comment 12•1 year ago
|
||
Thanks, please reopen with more details if it is still reproducible
Description
•