Drag and drop within the same tab freezes the entire browser sometimes
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: Kris, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0
Steps to reproduce:
Click and drag an element, so far I have tested: text, image, link
Drop it within the same tab, especially when done quickly/close to the original element (usually by an accident)
It doesn't always happen but can happen while I'm casually using the browser
Actual results:
The entire browser freezes (all windows that are open at the time (media like music etc continues to play)) and a system window that says Firefox is not responding pops up after a while.
Usually Firefox eventually unfreezes but that can take a long time.
Expected results:
"Nothing", i.e. the dragged image should disappear or an animation of the element floating back to its original spot should be played
|
Reporter | |
Updated•1 year ago
|
|
||
Comment 1•1 year ago
|
||
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.
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 2•1 year ago
|
||
Pardon me for the edits, it is my first report and I want to be thorough: While it does happen in my everyday, stable version of Firefox I have tested and reproduced it in the nightly version too
Do you still see it? Latest release should fix that.
Thanks.
|
|
Reporter | |
Comment 4•1 year ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
Do you still see it? Latest release should fix that.
Thanks.
Hi there, sorry for late reply, I have tried to replicate the bug and while the browser does slow down and lags for a moment it no longer freezes like before.
Version 135.0, stable.
Thank you for your help.
|
||
Comment 5•1 year ago
|
||
|
|
||
Comment 6•1 year ago
|
||
Hello,
I'm currently experiencing the same issue. Some information about my setup:
Version: 135.0 (64-bit) stable
Build from: https://hg.mozilla.org/releases/mozilla-release/rev/17c38d56ca552e154046a33a3ec8d3bb56ae00a1
Build target: x64_64-pc-linux-gnu
OS: Fedora Linux 41
Kernel: Linux 6.12.11-200.fc41.x86_64
Windowing System: X11
I have attached the stack trace information (gdb bt) from the browser in the hanging state. I hope this information helps to debug the issue.
Thank you,
Daniil
Please test latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Can you reproduce?
Thanks.
|
|
||
Comment 8•1 year ago
|
||
Hi Martin,
So far, I was unable to reproduce the bug on firefox-137.0a1.en-US.linux-x86_64. I will let you know if anything changes, however so far it seems like that nightly version has fixed my issue.
Thank you,
Daniil
|
|
||
Comment 9•1 year ago
|
||
(In reply to Daniil Glazko from comment #8)
Hi Martin,
So far, I was unable to reproduce the bug on firefox-137.0a1.en-US.linux-x86_64. I will let you know if anything changes, however so far it seems like that nightly version has fixed my issue.
Thank you,
Daniil
Given that there's a solution in the pipeline, not sure how useful this information is, but bug is still present in firefox-136.0b9.
|
||
Comment 10•1 year ago
•
|
||
This might have happened to me a couple of times by accident in the last week. Nightly/Wayland/Ubuntu 24.10, mozilla binaries, but unfortunately no clear STR.
|
|
||
Comment 11•1 year ago
|
||
Martin, if I find a way to repro what should I look at ? env variable ?
Run on terminal with MOZ_LOG="WidgetDrag:5" and if you see the freeze, switch to terminal and attach the log here.
Thanks.
|
|
||
Comment 13•1 year ago
|
||
Happened again, unfortunately i was not yet running with the log. Only one window had its top (everything at the top, including URL bar reload icons, or extensions icons): frozen
Okay, please try again.
|
|
||
Comment 15•1 year ago
|
||
this is what i collected, end of the log is when the blocked state is met
From the log end:
[Parent 1220814: Main Thread]: D/WidgetDrag mShell::drag_leave
[Parent 1220814: Main Thread]: D/WidgetDrag WindowDragLeaveHandler()
[Parent 1220814: Main Thread]: D/WidgetDrag Received dragleave after drag had ended.
[Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragFailed(791aa85df660) GTK_DRAG_RESULT_NO_TARGET
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][790c1b99e100] SourceEndDragSession(791aa85df660) result GTK_DRAG_RESULT_NO_TARGET
[Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(791aa85df660)
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][790c1b99e100] SourceEndDragSession(791aa85df660) result GTK_DRAG_RESULT_SUCCESS
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::nsDragSession()
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::InvokeDragSession
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::InvokeDragSessionImpl
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] numDragItems = 1
[Parent 1220814: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 1220814: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (791aaf96d660)
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::SourceBeginDrag(791aaf96d660)
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::SetDragIcon(791aaf96d660)
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] set drag popup [791b7dd66c00]
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] GdkDragContext [791aaf96d660] nsWindow [791bad7ad000]
[Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::EndDragSessionImpl(0) 0
Doesn't look like D&D freeze on Widget level - the D&D session was terminated and started again (nsDragSession::SourceBeginDrag). But I wonder why we don't see more lines after 'nsDragSession::EndDragSessionImpl' here. Was the log truncated?
If you see the freeze, can you try to do D&D on titlebar (where it's broken) and see if you're getting more lines to D&D log? And if you see new D&D lines log if you do D&D on working part of Firefox?
What I see is more like vsync/painting issues that D&D ones here.
Thanks.
|
|
||
Comment 17•1 year ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #16)
From the log end:
[Parent 1220814: Main Thread]: D/WidgetDrag mShell::drag_leave [Parent 1220814: Main Thread]: D/WidgetDrag WindowDragLeaveHandler() [Parent 1220814: Main Thread]: D/WidgetDrag Received dragleave after drag had ended. [Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragFailed(791aa85df660) GTK_DRAG_RESULT_NO_TARGET [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][790c1b99e100] SourceEndDragSession(791aa85df660) result GTK_DRAG_RESULT_NO_TARGET [Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(791aa85df660) [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][790c1b99e100] SourceEndDragSession(791aa85df660) result GTK_DRAG_RESULT_SUCCESS [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::nsDragSession() [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::InvokeDragSession [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::InvokeDragSessionImpl [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] numDragItems = 1 [Parent 1220814: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab [Parent 1220814: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal [Parent 1220814: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (791aaf96d660) [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::SourceBeginDrag(791aaf96d660) [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::SetDragIcon(791aaf96d660) [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] set drag popup [791b7dd66c00] [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] GdkDragContext [791aaf96d660] nsWindow [791bad7ad000] [Parent 1220814: Main Thread]: D/WidgetDrag [D 0][791422da6800] nsDragSession::EndDragSessionImpl(0) 0Doesn't look like D&D freeze on Widget level - the D&D session was terminated and started again (nsDragSession::SourceBeginDrag). But I wonder why we don't see more lines after 'nsDragSession::EndDragSessionImpl' here. Was the log truncated?
I dont think so, I manually killed by applying update and I was running firefox 2>&1 | tee so it should have flushed all buffers
If you see the freeze, can you try to do D&D on titlebar (where it's broken) and see if you're getting more lines to D&D log? And if you see new D&D lines log if you do D&D on working part of Firefox?
I dont have a titlebar
What I see is more like vsync/painting issues that D&D ones here.
Hm that might explain why CTRL+L works and I can still open tabs etc?
Thanks.
(In reply to :gerard-majax from comment #17)
If you see the freeze, can you try to do D&D on titlebar (where it's broken) and see if you're getting more lines to D&D log? And if you see new D&D lines log if you do D&D on working part of Firefox?
I dont have a titlebar
Sorry, tab bar.
What I see is more like vsync/painting issues that D&D ones here.
Hm that might explain why
CTRL+Lworks and I can still open tabs etc?
Not sure how CTRL+L popup is painted, if extra window or panting to recent one. "Widget:5" log will tell us more.
Description
•