Bug 464283 - Virtual window behaviour has changed and excludes the original behaviour
Summary: Virtual window behaviour has changed and excludes the original behaviour
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.26.5
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-14 15:44 UTC by Peter Humphrey
Modified: 2023-04-15 02:49 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Humphrey 2023-01-14 15:44:42 UTC
SUMMARY
Flexibility has been added in the displaying of new browser tabs (or windows) on clicking a link, but the original behaviour has been removed.

(See also bug 464280.)

STEPS TO REPRODUCE
1.  Open System Settings and go to Window Management | Window Behaviour | Advanced.
2. Select the desired Virtual Desktop behaviour, then save and exit.
3. Click a link somewhere.

OBSERVED RESULT
Wherever the browser happens to be at present, it is brought to the current desktop and sits on top of whatever is there already, regardless of the choice at 2 above. I reported this in bug 464280.

EXPECTED RESULT
There should be a third option: to keep the previous behaviour and leave all windows where they are.

Rationale:
If I'm opening a series of website links while reading, say, Gentoo news or release notes, I want my windows to stay where they are until I'm ready to read the new pages.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo ~amd64; base system release 2.9
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.8
Kernel version: 6.1.5-gentoo-r1
Comment 1 Andreas Sturmlechner 2023-01-14 22:07:35 UTC
You are citing a bug marked as duplicate of bug 462996, which contains a link to a fix here:

https://invent.kde.org/plasma/kwin/-/merge_requests/3380

Can you confirm that, after upgrading to KDE Frameworks 5.102 and applying that patch to kwin-5.26.5, your problem is fixed?
Comment 2 Peter Humphrey 2023-01-15 16:42:13 UTC
If I've done the patching without error, the patch makes no difference. The browser is still yanked from where it was to lie on top of everything on the current desktop.

I tried two ways of patching: the first time I followed the Gentoo stepwise ebuild process, issuing successive ebuild commands, with the patch after src-prepare; the second I simply dropped the patch file into /etc/portage/patches/kde-plasma/kwin-5.26.5/ and running the standard emerge command; that should have picked up the patch and applied it.

That isn't all. I run with Firefox on desktop 3, and I log in and out via sddm. Since upgrading to kde-frameworks-5.102 today, when I log out and then in again Firefox appears on desktop 1 regardless.
Comment 3 Peter Humphrey 2023-01-15 16:46:52 UTC
Is there some confusion between (i) the two new options in system settings and (ii) restoration of the original behaviour? I've been asked to test a patch relating to the former, whilst I am concerned with the latter, as I said in my bug report.
Comment 4 Nicolas Fella 2023-01-15 20:27:30 UTC
What's your "focus stealing prevention" setting?
Comment 5 Peter Humphrey 2023-01-16 00:18:30 UTC
Ah! It was Low, which I don't remember setting. But setting it to Medium has done the trick.

Thank you Nicolas. Another one bites the dust...
Comment 6 David Edmundson 2023-01-16 16:16:13 UTC
>Another one bites the dust...

So can this be considered closed?
Comment 7 Nicolas Fella 2023-01-16 16:29:54 UTC
There's something about this that I don't understand.

Based on reading the code the behavior is "if focus stealing protection is set to anything higher than 'None' then don't activate apps on other desktops". This part of the behavior didn't change recently. And yet we have multiple people saying it did.

What adds to the confusion is that we seem to have different behavior depending on *how* the app activates itself.

If the app activates itself by changing _NET_ACTIVE_WINDOW then (before https://invent.kde.org/plasma/kwin/-/commit/6b38b0372443b49246b2313673efb0e48a63a978) and focus stealing protection is none then we would switch to the app's desktop

If the app activates itself by changing _NET_STARTUP_ID then we would move the window to the current desktop (or the desktop explicitly specified in the startup id). If focus stealing protection is none then the window is activated. (https://invent.kde.org/plasma/kwin/-/merge_requests/3380 changed this behavior to not move to the current desktop unless the relevant option is chosen).

With https://invent.kde.org/plasma/kwin/-/merge_requests/3380 we now have (mostly) consistent behavior between the two cases. But neither https://invent.kde.org/plasma/kwin/-/merge_requests/3380 nor https://invent.kde.org/plasma/kwin/-/commit/6b38b0372443b49246b2313673efb0e48a63a978 changed the behavior of what happens when activating windows on another desktop with focus stealing protection other than None
Comment 8 Nicolas Fella 2023-01-16 16:32:54 UTC
>  If the app activates itself by changing _NET_STARTUP_ID then we would move the window to the current desktop (or the desktop explicitly specified in the startup id). If focus stealing protection is none then the window is activated.

Correction: at this point the window is already moved to the current desktop, so it is activated according to usual FSP rules
Comment 9 Peter Humphrey 2023-01-16 17:11:34 UTC
I've lost track of which bug report refers to which behaviour.

In my case, setting focus stealing prevention to not NONE cures the problem of my browser window being dragged onto the current desktop.

However, I'm not clear on whether the selection of move-to-desktop or move-browser-here works as it should.

Moreover, Firefox is loaded onto desktop 1 when I log in, regardless of where I left it.
Comment 10 Bug Janitor Service 2023-01-31 05:05:02 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Peter Humphrey 2023-01-31 12:09:12 UTC
What am I being asked for?
Comment 12 Nicolas Fella 2023-04-14 22:25:19 UTC
Git commit 8c9c45b8f101f1d90b3084530f9e463a2b5915ab by Nicolas Fella.
Committed on 14/04/2023 at 19:06.
Pushed by nicolasfella into branch 'master'.

Add option to do nothing when activating window on another desktop

Some users prefer this over the existing options. It e.g. allows to open
a bunch of links and only then switch to the browser on a different desktop

M  +12   -0    doc/windowbehaviour/index.docbook
M  +2    -0    src/activation.cpp
M  +5    -0    src/kcms/options/advanced.ui
M  +1    -0    src/kwin.kcfg
M  +2    -1    src/options.h

https://invent.kde.org/plasma/kwin/commit/8c9c45b8f101f1d90b3084530f9e463a2b5915ab