1875031 - Firefox's tab bar incorrectly displays the tab-position-mark that only appears when dragging and dropping web pages under KDE Plasma Wayland.

Status: RESOLVED FIXED

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

Description

[Albert Eureka]

Attachment: Screenshot_20240117_171231.png

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

Steps to reproduce:

1.Switch to KDE Plasma Wayland Protocol edition, open firefox
2.open some web pages, select, copy, or drag and drop something
3.if nothing happens, repeat step 2

Actual results:

You will see a tab-position-label appear in the tab bar that only appears when dragging a web page tab

This problem has appeared in many versions of KDE Plasma, whether it is KDE Plasma 5.27.10 or Plasma 6, and it has also appeared in various versions of firefox.

Additional information:
OS: openSUSE Tumbleweed(Linux 6.6.11)(also appeared in ArchLinux and Debian KDE)
Desktop: KDE Plasma 5.27.10(also in 5.27.9, 5.27.8...)
Window protocol: Wayland

Expected results:

tab-position-mark should not be displayed

Comment 1

[Dão Gottwald [:dao]]

Would you be able to do a screen recording while reproducing the bug? We're not sure we fully understand the steps you took.

Comment 2

[Albert Eureka]

Attachment: video description

Comment 3

[Albert Eureka]

The appearance of the mark in the tab bar is completely random, and you cannot predict whether it will appear or not.
This mark usually only appears when you drag and drop content, indicating where you place the target in the tab bar.

Comment 4

[Albert Eureka]

My scenario:
OS: openSUSE Tumbleweed x86_64
Kernel: 6.6.11-1-default
DE: Plasma 5.27.10
WM: kwin
GPU: Intel Alder Lake-P GT2 [Iris Xe Graphics]
Window protocol: Wayland

Comment 6

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

Can you please run Firefox on terminal with MOZ_LOG="WidgetDrag:5" env variable, record the log and quit Firefox if you see the mark for first time?
Thanks.

Comment 8

[chengyuhui1]

Attachment: drag.log

Here you are. I noticed that there are new log entries whenever the focus is switched from other applications to Firefox after the bug is triggered (the indicator does not always appear).

Comment 9

[chengyuhui1]

Attachment: Screencast of the indicator when copying a URL on GitHub.webm

It seems that Firefox keeps firing WindowDropPosition at the position the last (real) drop event happened, whenever the focus is changed or clipboard is updated (anything that updates the clipboard: Ctrl-C, context menu, or web API).
On my system, the indicator only appears when it is positioned between two tabs (just like what should happen when real DnD happens). It disappears whenever it is inside a tab and any triggering event happens, and reappears when conditions are met.

Comment 10

[Albert Eureka]

Here is my log, I noticed that as @chenyuhui1 said above, this bug is triggered whenever you perform an operation such as copying or pressing Ctrl-C after dragging.

I have recorded in this log when dragging ends and when copying starts.
When I copied something after drag-and-dropping, here is the output

[Parent 9284: Main Thread]: D/WidgetDrag WindowDragMotionHandler target nsWindow [7f202abe2e00]
[Parent 9284: Main Thread]: D/WidgetDrag WindowDropPosition [677, 0]
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::Schedule(7f20512bed40) task eDragTaskMotion window 7f202abe2e00
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::UpdateDragAction(7f20512bed40)
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_context_get_actions() returns 0x0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_context_get_selected_action() returns 0x4
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   set explicit move
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::ReplyToDragMotion(7f20512bed40) can drop 1
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   set explicit action move
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_status() action 4
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::RunScheduledTask() task eDragTaskMotion mTargetWindow 0 mPendingWindow 7f202abe2e00
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::StartDragSession
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   start drag session mTargetWindow 7f202abe2e00 mTargetWidget 7f203b1ef660
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   mPendingDragContext 7f20512bed40 => mTargetDragContext 0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   process motion event
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::UpdateDragAction(7f20512bed40)
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_context_get_actions() returns 0x0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_context_get_selected_action() returns 0x4
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   set explicit move
[Parent 9284: Main Thread]: D/WidgetDrag nsWindow::DispatchDragEvent
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::GetNumDropItems
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::GetTargetDragData(7f20512bed40) 'text/uri-list'
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   text/uri-list is missing
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   NumOfDropItems 1
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) application/x-moz-file
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   application/x-moz-file is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) application/x-moz-custom-clipdata
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   application/x-moz-custom-clipdata is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) application/x-moz-file
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   application/x-moz-file is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) text/html
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/html => text/html
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/_moz_htmlinfo => text/html
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/_moz_htmlcontext => text/html
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) text/x-moz-url
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   text/x-moz-url is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) text/x-moz-url-data
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   text/x-moz-url-data is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) text/plain
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/plain => text/plain
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/html => text/plain
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/_moz_htmlinfo => text/plain
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   supported, with converting text/_moz_htmlcontext => text/plain
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::IsDataFlavorSupported(7f20512bed40) image/png
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   image/png is not supported
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::SetCanDrop 1
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::ReplyToDragMotion(7f20512bed40) can drop 1
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   set explicit action move
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   gdk_drag_status() action 4
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   clear mTargetWindow mTargetWidget and other data
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   remove task source
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 0]: nsDragService::Schedule(0) task eDragTaskLeave window 0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::RunScheduledTask() task eDragTaskLeave mTargetWindow 7f202abe2e00 mPendingWindow 0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   dispatch eDragExit (7f202abe2e00)
[Parent 9284: Main Thread]: D/WidgetDrag nsWindow::DispatchDragEvent
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::EndDragSession(0) 0
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 1]:   quit, selected task eDragTaskLeave
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 0]: nsDragService::Observe("quit-application")
[Parent 9284: Main Thread]: D/WidgetDrag [Depth 0]: nsDragService::~nsDragService

However, if I do not drag and drop, but simply copy something, the above will not appear.

It seems that Firefox did not completely clear the drag-and-drop completed flag.

Comment 11

[Albert Eureka]

Attachment: firefox.log

Comment 12

[Albert Eureka]

This bug does not appear under Windows, Linux X11 and Linux Gnome Wayland, Only KDE Wayland

Maybe it's KDE Wayland's bug?

Comment 13

[Albert Eureka]

I launched firefox under KDE X11 and reproduced the same operations, here is some of my output

[Parent 28578: Main Thread]: D/WidgetDrag WindowDropPosition [775, 0]
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::Schedule(7f10ac524120) task eDragTaskDrop window 7f10d0c6d500
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::RunScheduledTask() task eDragTaskDrop mTargetWindow 7f10d0c6d500 mPendingWindow 7f10d0c6d500
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::StartDragSession
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   start drag session mTargetWindow 7f10d0c6d500 mTargetWidget 7f10d0c2e960
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   mPendingDragContext 7f10ac524120 => mTargetDragContext 0
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   process drop task
[Parent 28578: Main Thread]: D/WidgetDrag nsWindow::DispatchDragEvent
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   drag finished
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]: nsDragService::EndDragSession(7f10ac524120) 1
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   clear mTargetWindow mTargetWidget and other data
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 1]:   remove task source
[Parent 28578: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(7f10ac567c80)
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 0]: SourceEndDragSession(7f10ac567c80) result GTK_DRAG_RESULT_SUCCESS
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 0]: nsDragService::Observe("quit-application")
[Parent 28578: Main Thread]: D/WidgetDrag [Depth 0]: nsDragService::~nsDragService

// FINISH DRAG AND DROP
// END OF FILE

unlike KDE Wayland, when I finished drag and dropping, the nsDragService object was destroyed

Comment 14

[chengyuhui1]

(In reply to Albert Eureka from comment #12)

This bug does not appear under Windows, Linux X11 and Linux Gnome Wayland, Only KDE Wayland

Maybe it's KDE Wayland's bug?

It's probably some weird interaction between Firefox and KDE Wayland, some users on Reddit suspected that a Plasma update last year (around this time?) broke this. I was unable to reproduce this under any other combination (e.g. Gnome Wayland), but Firefox versions as old as 2021 exhibits this, it's unlike that something in Firefox broke horribly.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Yeah, I can reproduce... EndDragSession doesn't seem to be ending the drag session properly... Should be easy to chase down in rr...

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1875031 - Don't keep pending drag context alive after EndDragSession. r=stransky

Otherwise we might keep receiving drag motion events, which are
unexpected and can confuse other code.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6c14242aa73e
Don't keep pending drag context alive after EndDragSession. r=stransky

Comment 18

[Iulian Moraru]

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

Comment 19

[Albert Eureka]

On the latest firefox-nightly (2024.3.29), I verified that this bug had been fixed, however, bug 1882963, which is marked as duplicate of this bug, is still not fixed

Comment 20

[Albert Eureka]

Then I tried dragging on chromium (wayland), and a similar bug appeared. However, the bug in chromium was not as obvious as in firefox. There was no problem with the chromium tab bar, but there was a problem with the mouse cursor style:
Generally, when our mouse is hovering over an input box, the cursor will turn into a line. When hovering over a hyperlink, the cursor will then turn into a claw shape. But when I drag the hyperlink on chromium wayland, the mouse cursor under the above element does not change into the style it should be - it is just a simple arrow shape. I guess at this time kwin_wayland and the GTK backend still think that we are dragging a hyperlink, so the cursor is still the shape shown when dragging.
What is certain is that KDE Wayland does have bugs. This is not a problem with firefox or chromium, but a problem with GTK under kde wayland.

Comment 21

[Albert Eureka]

Attachment: 2024-04-01 18-18-39.mp4

Comment 22

[Albert Eureka]

I will submit the details of this bug to kde bugzilla later

Comment 23

[Emilio Cobos Álvarez (:emilio)]

(In reply to Albert Eureka from comment #19)

On the latest firefox-nightly (2024.3.29), I verified that this bug had been fixed, however, bug 1882963, which is marked as duplicate of this bug, is still not fixed

Let's reopen that instead of this?

Comment 24

[jackyzy823]

Some reference:
https://bugs.kde.org/show_bug.cgi?id=464196
https://gitlab.gnome.org/GNOME/gtk/-/issues/5519

The problem is that plasma(klipper(ksystemclipboard)) is sending "selection" and "primary selection" every time a window is activated, which gtk detects as drag move events.

Comment 25

[Albert Eureka]

(In reply to jackyzy823 from comment #24)

Some reference:
https://bugs.kde.org/show_bug.cgi?id=464196
https://gitlab.gnome.org/GNOME/gtk/-/issues/5519

The problem is that plasma(klipper(ksystemclipboard)) is sending "selection" and "primary selection" every time a window is activated, which gtk detects as drag move events.

Yeah, it's a GTK-under-kwin bug

Comment 26

[Albert Eureka]

When I tested according to the reproduction steps of KDE bug 464196, I found that after performing a drag-and-drop operation on Firefox, if I switch to another application and then switch back to Firefox (firefox regains focus), it will also trigger this bug

Further, I found that WaylandClipboard::setMimeData in waylandclipboard.cpp, KGuiAddons is probably the source of this bug