1882963 - [KDE/Wayland] After dragging links onto a tab, it randomly gains focus

Status: RESOLVED WORKSFORME

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

Description

[chengyuhui1]

Attachment: Screenshot_20240301_143917.png

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

Steps to reproduce:

Environment: Manjaro, KDE Plasma, Wayland (about:support says wayland).

1. Drag a link or selected text onto the tab bar, creating a new tab or reusing existing ones

Actual results:

The affected tab will regain focus when I:
a. Switch to another application and back to FF
b. Copy anything in FF (context menu or Ctrl-C)
c. Initiate drag-and-drop in any tab

Sometimes the drag-and-drop indicator will remain on the tab bar, and if I closed tabs so that the indicator is on top of a certain tab, it will gain focus when I do the actions described above.

Similar bug with almost the same setup is described in https://www.reddit.com/r/firefox/comments/y69wwj/strange_tabswitching_when_switching_focus_or/

Expected results:

Other tabs should not gain focus when I switch windows.

Comment 1

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Can you create a screencast of it please?
Thanks.

Comment 2

[chengyuhui1]

Attachment: Screencast of the tab switching behavior

Screencast attached, note that I never manually switched tabs in this video.

Comment 3

[chengyuhui1]

The behavior of the dragging indicator (as shown in screenshot) is more random, it shows up or disappears randomly when FF loses and re-gains focus, and sometimes even snaps to the nearest gap when I close tabs so that it is no longer positioned between two tabs. At least I think that it should not be there.
I was unable to capture a screencast as for now because it would disappear the moment I start recording and switch back to FF.

Comment 4

[chengyuhui1]

Attachment: Screencast of how the indicator usually behaves

This screencast shows how the indicator usually behaves: re-gaining focus and I'm switched to the tab under it.

Comment 5

[chengyuhui1]

mozregression shows that even 2021-07-01 has this bug (older versions crash on my system). Both of my systems (one Manjaro, one vanilla Arch) exhibit this behavior (along with that Redditor), and it is not related to extensions since mozregression creates an empty profile.

Comment 6

[chengyuhui1]

Another report on Reddit: https://www.reddit.com/r/firefox/comments/126rtip/copyingcutting_text_switches_to_another_tab/
It seems to be a KDE-specific thing and related to versions around Plasma 5.27.3, but I currently have no time to verify that...

Comment 7

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Looks like a dupe of Bug 1875031.

Comment 8

[chengyuhui1]

Can confirm that the build 2024-03-28 19:25:51.721000, revision 55aaac63 is still bad after the fix of Bug 1875031.

Comment 9

[chengyuhui1]

Drop events are still firing upon Ctrl-C in logs.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

I can repro with the STR from comment 0.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

It's easier to just drag from urlbar to tab bar. Ctrl+C will re-show the drop indicator.

Comment 12

[chengyuhui1]

As is analyzed in Bug 1875031, https://invent.kde.org/frameworks/kguiaddons/-/blob/master/src/systemclipboard/waylandclipboard.cpp?ref_type=heads#L589 is probably what causing this (both why GTK recognizes this as a drop and KDE sends these events is a puzzle to me).

Comment 13

[Dragoon Aethis]

It appears that Sublime Text is also affected by odd drag-drop issues, only on KDE + Wayland: https://github.com/sublimehq/sublime_text/issues/4077

Comment 14

[Albrecht0xff]

I can confirm that this bug and bug 1875031 has been fixed in KDE Plasma 6.0.4 Wayland released on 2024.4.16
See also: https://kde.org/announcements/plasma/6/6.0.4/

Comment 15

[chengyuhui1]

I've also noticed that this bug is gone after my recent update to KWin 6.0.4 on Manjaro. Should we mark this as fixed?

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Yes