1917854 - [KDE][X11] Firefox will freeze and get unresponsive when dragging and marking text (video included)

Status: RESOLVED FIXED

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

Description

[:Yoinker]

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

Steps to reproduce:

I'll provide a video on how to produce it. Please watch it till the end, you'll see how firefox will unfreeze at some point.
Starting firefox from the Terminal wont provide any error whatsoever. Firefox will also not crash, there is no log or anything i can provide when checking the Journal.

I was able to reproduce this on 2 different computers, running Arch. One computer uses a RX7700XT another uses RX6600.

Actual results:

Firefox freezes, no click will get detected anymore.. after a few seconds firefox then comes back to life and does all clicks at once..

Expected results:

It shouldn't freeze

Comment 1

[:Yoinker]

Video didn'T seem to upload so here's a link
https://streamable.com/0dxw9c

Comment 2

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

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

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Looks like the D&D operation is still going on so you can't interact with Firefox and it's eventually canceled so it works again.

Comment 4

[:Yoinker]

Problem is, this also happens during normal browsing. This is just a way to provoke it to happen. Sometimes it's enough just to click on a link to make this happening. So i don't think it is actually the drag and drop. It's just a way to provoke it. it's just a coincidence that the "drag" part was still going in my video i'd say.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

You may unintentionally perform D&D while regular browsing, just for a split of second. It's enough to hold mouse button while cursor is moving.
Please try to run Firefox on terminal with MOZ_LOG="WidgetDrag:5" env variable and attach the log here. Like:

MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1

also please attach your about:support page.
Thanks.

Comment 6

[:Yoinker]

Attachment: log.txt

Sorry it took me so long (had covid). I'm uploading the logfile and the about:config text as well.
I also reproduced the bug when logging (guess that is what you wanted?)

Comment 7

[:Yoinker]

Attachment: aboutsupport.txt

Comment 8

[nodeadbatteries]

Attachment: log_2.txt

Another set of logs with MOZ_LOG="WidgetDrag:5", where I attempted to drag text twice in this session

Comment 9

[nodeadbatteries]

Attachment: aboutsupport_2.txt

My corresponding about:support data. I have been experiencing this issue as well when dragging text.

Comment 11

[Bruno J.]

Hello,
I noticed this also happens when drag&dropping external things onto firefox and not only elements from within firefox itself.
For example : Drag&drop a PNG file from KDE dolphin onto firefox.
There is a random chance Firefox will either

• reject the drop for no reason
• Accept the drop and open the file
• Freeze the whole UI for several seconds, like the inital scenario describes

I also found that simply passing over firefox with a dragged external item (still a png file for example or external text) without even releasing onto firefox will freeze the firefox UI.

Another notable thing is that while the firefox UI is frozen, my system is mostly unaffected, other applications respond fine, I can open new ones, except gwenview. There might be some specific bad interactions with KDE, as I see OP is also using KDE like me?

Comment 12

[:Yoinker]

@Bruno J.
Yes i'm also using KDE.
It's a pretty annoying issue. It can sometimes happen by just dragging a single word "accidentally". I'm also not sure if it might be related to AMD/MESA since so far it didn't happen on my old NV System. I usually just wait till Firefox becomes responsive again. Which sometimes can take up to a Minute.

Comment 13

[:Yoinker]

Oh and i also just tested the "simply passing over" also happens here. Just dragging something into firefox and firefox will freeze lol.

Comment 14

[Pancho]

I've also been experiencing this issue for over a month. EndeavourOS, Gnome, Nvidia GPU. Dragging text within Firefox will freeze it every time. I have to kill the process and restart Firefox.

Comment 15

[:Yoinker]

Do you guys have a higher resolution than 1080p? I have 2 other Systems where i can't seem to reproduce it. At least the "simply passing over" will not crash these systems.

The difference between the Systems are:

RX7700XT/1440/DisplayPort - there both happens: If dragging text a few times or just pulling any file into the ui (as Bruno discribed) and firefox will freeze

RX6600/1080p/HDMI- doesn't happen - only dragging text seem to cause the freeze there, but it seems to happen less frequently

GTX970/1080p/HDMI- doesn't happen - not having the issue on that System

Comment 16

[Pancho]

(In reply to :Yoinker from comment #15)

Do you guys have a higher resolution than 1080p? I have 2 other Systems where i can't seem to reproduce it. At least the "simply passing over" will not crash these systems.

The difference between the Systems are:

RX7700XT/1440/DisplayPort - there both happens: If dragging text a few times or just pulling any file into the ui (as Bruno discribed) and firefox will freeze

RX6600/1080p/HDMI- doesn't happen - only dragging text seem to cause the freeze there, but it seems to happen less frequently

GTX970/1080p/HDMI- doesn't happen - not having the issue on that System

Yeah, I'm on 4K/HDMI, RTX 4070ti, single monitor.

Comment 17

[Bruno J.]

I'm usually on dual monitor 2560x1440 + 1680x1050
But I was able to reproduce both scenarios (drag&drop text from within a web page, and passing over with a file) in single monitor 1080p configuration.

RX7900GRE with DDX amdgpu

Comment 18

[cproo12]

Happens with me as well. Here is info about my system:

hardware:
i7 10700k, 32gb ddr4, rtx 3090, OS drive some random m.2

software: (all latest/rolling release)
os: arch linux
display server: X
compositor: picom
window manager: awesomewm
file manager: Thunar (with GVFS installed)

i have all the same symptoms of others listed here, and have been dealing with it for around a month at this point. mine freezes for 15 seconds or so. usually i just kill firefox and restart it.

Comment 19

[cproo12]

my apologies, should have also included that I am using the latest proprietary nvidia driver.

otherwise, my system is pretty minimal. if there are any commands i can run to help troubleshoot let me know.

sorry- couldn't figure out how to edit my last post.

Comment 20

[:Yoinker]

Have you guys also noticed that https://bugzilla.mozilla.org/show_bug.cgi?id=1927253 it is very easy to "overlook" but somehow i think the two issues might be related since i first noticed them at about the same time. My guess is that this is related with some issues with HW-Acceleration. But I'm just guessing and trying to find some connection to this.

Comment 21

[cproo12]

(In reply to :Yoinker from comment #20)

My guess is that this is related with some issues with HW-Acceleration. But I'm just guessing and trying to find some connection to this.

I have never had HW acceleration enabled on my browser as it caused all kinds of stuttering problems. Still always had this issue, so I don't think they are related.

Comment 22

[Bruno J.]

Still happening with Firefox 132.0

Comment 23

[:Yoinker]

@Bruno J. Thought he issue with dragging files into firefox has been fixed for me it seems. At least i couldn't reproduce it yet.

Comment 24

[:Yoinker]

Spoke too early the dragging files into the UI still causes it to happen.

Comment 25

[:Yoinker]

I made some very interesting discoveries:
When firefox is in window mode and you'll drag a file from the top into firefox, firefox will NOT stuck. However if you drag the file from the right side into it, it will stuck!

Though there also is a workaround when dragging a file from the side into firefox: First the symbol will look like https://imgur.com/OuBFb4U Keep holding your mouse till the symbol changes to https://imgur.com/YFRlKke if you don't wait. It will stuck. If you'll wait till the symbol changes it wouldn't lol

Comment 26

[Bruno J.]

(In reply to :Yoinker from comment #25)

I made some very interesting discoveries:
When firefox is in window mode and you'll drag a file from the top into firefox, firefox will NOT stuck. However if you drag the file from the right side into it, it will stuck!

I can reproduce the UI freeze from all 4 sides when dragging a file over the firefox window.
Though it does seem to be slightly more rare when dragging from the top, but it still happens and I can reproduce it easily.

Though there also is a workaround when dragging a file from the side into firefox: First the symbol will look like https://imgur.com/OuBFb4U Keep holding your mouse till the symbol changes to https://imgur.com/YFRlKke if you don't wait. It will stuck. If you'll wait till the symbol changes it wouldn't lol

My guess is that "Keep holding your mouse till the symbol changes" is simply waiting for the freeze to go away, this is not solving anything, this is just waiting for the freeze to be over and UI to be responsive again.

Comment 27

[:Yoinker]

(In reply to Bruno J. from comment #26)

My guess is that "Keep holding your mouse till the symbol changes" is simply waiting for the freeze to go away, this is not solving anything, this is just waiting for the freeze to be over and UI to be responsive again.

I'd think the same though it is odd since the icon (on first link) wouldn't appear all all for me when dragging files from the "top". So i think it might be related. On my other systems where it doesn't happen at all the icon wouldn't appear no matter from which side i drag-in the files.

Comment 28

[Martin Stránský [:stransky] (ni? me)]

Thanks for the logs, I hope to look at ti soon.

Comment 29

[Bruno J.]

Without much surprise, still happening with firefox 132.0.2

Comment 30

[[:eddyb]]

Could the user impact be entirely from the timeout increase (from 1 to 5 seconds, if I am reading this change correctly)?

[Linux] Increase D&D timeout to 5 seconds as D&D operations should not timeout even on high load r=emilio
https://hg.mozilla.org/mozilla-central/rev/6b2409c9e7cf
https://phabricator.services.mozilla.com/D209341

That is, maybe it was timing out before, too, but just fast enough to not be as noticeable?

(Oh, whoops, wanted to cc the author, but that's stransky, already in charge of this bug)

For the record, I had only heard about this bug from a friend, I've never experienced it myself on Wayland
(though no idea if X11 vs Wayland is relevant, and I've failed to repro in a fresh profile with XWayland).

Comment 31

[:Yoinker]

Bruno could you also try to reproduce the issue i have reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1931319
I just wonder if there are more similarities since we both have RX7000 Series card.

Comment 32

[Zhai Can]

According to my local tests, this issue happens with Firefox version tag FIREFOX_NIGHTLY_130_END (including all after it, e.g. 131, 132 and the latest commit) but not with FIREFOX_NIGHTLY_129_END, in mozilla-central repository.

I'm using Nvidia 3060 Mobile wholly (using nvidia-xconfig-generated X11 config) with an external HDMI monitor.

For some reason this happens very heavily to me. When I drag images, the console outputs assertion errors; for texts, there's nothing.

Demonstration videos:

• 130_END: https://www.youtube.com/watch?v=ewIQeFKwSFk (see the description for time points I did the drags)
• 129_END: https://www.youtube.com/watch?v=4fbDB-h3eGw (issue not encountered)

OS: Arch linux rolling; kernel: 6.11.8. Graphics: X11+i3wm+picom

Comment 33

[Thomas]

This is still a problem. It happens frequently and totally disrupts my browsing experience, forcing me to sit and stare for a minute every single time.

IceWM, X11, Radeon RX 6700 XT, Arch 6.6.62-1-lts.

So it's not just KDE.

I've noticed that when FF freezes, the number of context switches per second massively increases, from 200-2000 up to 3500. It's all the main thread (lowest PID) doing the context switches, no other threads have high switch rates during a freeze in htop. Here's an image of htop while it happens.

Backtrace during a freeze:

#0  0x00007c1047c9fa19 in ?? () from /usr/lib/libc.so.6
#1  0x00007c1047ca27e2 in pthread_cond_timedwait () from /usr/lib/libc.so.6
#2  0x00007c10480f38cb in ?? () from /usr/lib/libnspr4.so
#3  0x00007c10480f971b in PR_WaitCondVar () from /usr/lib/libnspr4.so
#4  0x00007c1048103fa6 in PR_Sleep () from /usr/lib/libnspr4.so
#5  0x00007c103fa9e31c in ?? () from /usr/lib/firefox/libxul.so
#6  0x00007c103fa9b47e in ?? () from /usr/lib/firefox/libxul.so
#7  0x00007c103eb5f0e0 in ?? () from /usr/lib/firefox/libxul.so
#8  0x00007c103eb5d862 in ?? () from /usr/lib/firefox/libxul.so
#9  0x00007c103eb795b7 in ?? () from /usr/lib/firefox/libxul.so
#10 0x00007c103f67d384 in ?? () from /usr/lib/firefox/libxul.so
#11 0x00007c103f67d532 in ?? () from /usr/lib/firefox/libxul.so
#12 0x00007c103eb4d86f in ?? () from /usr/lib/firefox/libxul.so
#13 0x00007c103fc9b84c in ?? () from /usr/lib/firefox/libxul.so
#14 0x00007c103fc995ba in ?? () from /usr/lib/firefox/libxul.so
#15 0x00007c103f9c60bb in ?? () from /usr/lib/firefox/libxul.so
#16 0x00007c103f9c5f23 in ?? () from /usr/lib/firefox/libxul.so
#17 0x00007c103fa35213 in ?? () from /usr/lib/firefox/libxul.so
#18 0x00007c103f9ce4a6 in ?? () from /usr/lib/firefox/libxul.so
#19 0x00007c103f9cc18e in ?? () from /usr/lib/firefox/libxul.so
#20 0x00007c103fa52a2e in ?? () from /usr/lib/firefox/libxul.so
#21 0x00007c103fa951a0 in ?? () from /usr/lib/firefox/libxul.so
#22 0x00007c103fa9453f in ?? () from /usr/lib/firefox/libxul.so
#23 0x00007c1045a21a0a in ?? () from /usr/lib/libglib-2.0.so.0
#24 0x00007c1045a20559 in ?? () from /usr/lib/libglib-2.0.so.0
#25 0x00007c1045a83157 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007c1045a1fa55 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#27 0x00007c103bd9f38e in ?? () from /usr/lib/firefox/libxul.so
#28 0x00007c103bdb28c9 in ?? () from /usr/lib/firefox/libxul.so
#29 0x00007c103bdb243e in ?? () from /usr/lib/firefox/libxul.so
#30 0x00007c103bdb226e in ?? () from /usr/lib/firefox/libxul.so
#31 0x00007c104037e4e5 in ?? () from /usr/lib/firefox/libxul.so
#32 0x00007c103c0b422d in ?? () from /usr/lib/firefox/libxul.so
#33 0x00007c103beb4e55 in ?? () from /usr/lib/firefox/libxul.so
#34 0x00007c103beb4b1d in ?? () from /usr/lib/firefox/libxul.so
#35 0x000055c19505ba43 in ?? ()
#36 0x00007c1047c34e08 in ?? () from /usr/lib/libc.so.6
#37 0x00007c1047c34ecc in __libc_start_main () from /usr/lib/libc.so.6
#38 0x000055c1950bacd5 in _start ()

Looks like it's stuck waiting for a condition variable.

Attaching with strace during a freeze gives me a ton of these:

[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=455807000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=455869000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=455931000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=455993000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456056000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456118000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456180000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456242000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456304000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
[pid  2612] futex(0x7c1047a63500, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  2612] futex(0x7c0fe2212770, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1732903871, tv_nsec=456366000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)

Comment 34

[:Yoinker]

Agree it's annoying and seem like nobody actually cares. This and some other reports of mine that got like no attention made me finally switch to brave. It's annoying since i really dislike chromium but i mean the issue is still considered "UNCONFIRMED". Although the issue is easy to reproduce. I just gave up on Firefox at this point.

Comment 35

[aeqwaa]

Same problem on i3wm, x11, nvidia, archlinux .... nobody seems to care gonna switch to brave or something else ...

Comment 36

[Thomas]

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

Thanks for the logs, I hope to look at ti soon.

It's been four weeks. Which information do you need to make progress on this bug, anything we can help with? If you don't have time, can you pass it on to someone who does?

Comment 37

[markus_austria]

Until today, this problem plagued countless of our Office PCs for months.
Finally we resolved it, by switching everything to Chrome and giving up on waiting for Mozilla, which has, is and will always be a lost cause.

Comment 38

[Martin Stránský [:stransky] (ni? me)]

Sorry for the delay here. The bug is caused by X11/MOTIF D&D protocol, we primary target Wayland here so it's a bit out of radar.
Looking at it right now.

Comment 41

[Łukasz]

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

Sorry for the delay here. The bug is caused by X11/MOTIF D&D protocol, we primary target Wayland here so it's a bit out of radar.
Looking at it right now.

Serio? Oficjalnie wspieracie coś, to jest w fazie testów, a nie wspieracie czegoś, co jest aktualnie używane przez ludzi?

Wayland barely has support on some graphics cards, some on desktop environments.

Comment 42

[Martin Stránský [:stransky] (ni? me)]

The problem is that if Firefox is both source and destination of D&D operation, on X11 we're getting D&D failed signal on source side (handled by Gtk) so we clear&remove the D&D data. But destination side (also handled by Gtk) still posts D&D move signals and also data-ready ones so we're trying to read the data but they're already cleared.

I guess we had always this bug here but it was made visible by increased timeout (from Bug 1881229).

Comment 43

[Martin Stránský [:stransky] (ni? me)]

(In reply to Łukasz from comment #41)

Wayland barely has support on some graphics cards, some on desktop environments.

I don't say it works perfectly everywhere and on all scenarios but it's the direction where Linux desktop is moving and what most of Linux developers use.

Comment 44

[Łukasz]

Attachment: Firefox drag&drop bug.mp4

Comment 45

[Łukasz]

Cinnamon/GNOME has the same problem.

Comment 46

[Łukasz]

Attachment: Firefox drag&drop bug text and video.mp4

Comment 47

[Łukasz]

In my opinion, this is a regression compared to this point: https://bugzilla.mozilla.org/show_bug.cgi?id=1881971

Back then, I fixed it, and the issue stopped occurring. It came back some time ago, in an even more severe form.

Comment 48

[Martin Stránský [:stransky] (ni? me)]

Yeah, let's fix that properly on OS level.

Comment 49

[Martin Stránský [:stransky] (ni? me)]

Bug 1934919 may make this bug less painful.

Comment 50

[Thomas]

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

The problem is that if Firefox is both source and destination of D&D operation, on X11 we're getting D&D failed signal on source side (handled by Gtk) so we clear&remove the D&D data. But destination side (also handled by Gtk) still posts D&D move signals and also data-ready ones so we're trying to read the data but they're already cleared.

I guess we had always this bug here but it was made visible by increased timeout (from Bug 1881229).

Thank you for looking into it!

I just looked a bit at nsDragService.cpp and I have a couple questions. (Feel free to just ignore them if they're stupid, I've got zero experience with the FF code base.)

• why does nsDragService::GetTargetDragData busy-loop instead of just handling the GtkWidget::drag-data-received signal that drag_get_data causes?
• the call to gtk_main_iteration can block if there are no events, would that cause issues / hangs? Should we check gtk_events_pending first?
• how come the timeout is on the order of 100-500 ms, but the hangs last for 30 seconds or more?
• what about drags from/to other applications, or dragging between two other applications, just "passing over" Firefox? Some people reported this could also cause hangs

Comment 51

[Martin Stránský [:stransky] (ni? me)]

(In reply to Thomas from comment #50)

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

The problem is that if Firefox is both source and destination of D&D operation, on X11 we're getting D&D failed signal on source side (handled by Gtk) so we clear&remove the D&D data. But destination side (also handled by Gtk) still posts D&D move signals and also data-ready ones so we're trying to read the data but they're already cleared.

I guess we had always this bug here but it was made visible by increased timeout (from Bug 1881229).

Thank you for looking into it!

I just looked a bit at nsDragService.cpp and I have a couple questions. (Feel free to just ignore them if they're stupid, I've got zero experience with the FF code base.)

• why does nsDragService::GetTargetDragData busy-loop instead of just handling the GtkWidget::drag-data-received signal that drag_get_data causes?

It's because GtkWidget::drag-data-received is received from the loop - as the loop gets events/data from system.

• the call to gtk_main_iteration can block if there are no events, would that cause issues / hangs? Should we check gtk_events_pending first?

There's no difference here - we need to wait in the code on the place as the code is sync and we're required to return result there.
Blocking event helps to same resources / CPU as it doesn't spin the loop.

• how come the timeout is on the order of 100-500 ms, but the hangs last for 30 seconds or more?

Because Firefox requests more than one MIME type and the timeout is for each + some MIME types gets fallbacks (like URI type can be converted from text/plain). It depends how many MIME types is requested by Firefox. But I'll look to do negative cache and cancel already failed requests.

• what about drags from/to other applications, or dragging between two other applications, just "passing over" Firefox? Some people reported this could also cause hangs

That should generally works - if you get data from other app to Firefox and Firefox query the data, the request is directly handled to the other application and D&D waits for it. The timeout applies there too so if the app is not responding is the same scenario.

Comment 52

[Martin Stránský [:stransky] (ni? me)]

Another complication here is that X11 finishes source D&D operation but target one is still going on. As we use the same content for source and destination with shared cache, we invalidate it when D&D source is finished.

Then we're hitting freeze/timeout as we want to read data for destination operation but we have empty cache so we need to ask OS for new one, but the operation is already terminated so we don't get anything. But I wonder why it takes so long Gtk/X11 to just say "we have nothing for you".

Comment 55

[Martin Stránský [:stransky] (ni? me)]

We should be covered now by fixed Bug 1935083 and Bug 1934919.

Comment 56

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

Set release status flags based on info from the regressing bug 1881229

Comment 58

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

Set release status flags based on info from the regressing bug 1881229