Bug 419867

have the same problem, Arch Linux again.

though i just tried logging into my backup user account and virtual screen switching worked fine.
Desktop settings/Mouse Actions/Vertical-Scroll set to Switch-Desktop.

perhaps a bad setting somewhere but not sure where to look.

*** Bug 419878 has been marked as a duplicate of this bug. ***

related to bug 413104

*** Bug 419961 has been marked as a duplicate of this bug. ***

I created a temporary workaround with xbindkeys and xdotool.

In ~/.xbindkeysrc I added the lines:

"bash /home/username/scroll_down.sh"
    b:5
"bash /home/username/scroll_up.sh"
    b:4


The contents of the shell files are:

#!/bin/bash
eval $(xdotool getmouselocation --shell)
name=$(xdotool getwindowname $WINDOW)
base="Desktop — Plasma"

if [ "$name" = "$base" ]; then
    qdbus org.kde.KWin /KWin nextDesktop
fi

With "nextDesktop" in the scroll_down/sh file and "previousDesktop" in the scroll_up.sh file.
The "qdbus" command could also be replaced with "xdotool set_desktop"

This assumes that you have two desktops stacked vertically.
Also there is no wrap around scrolling.

Seeing the same issue on Manjaro after the most recent update.

This is working for me in Plasma 5.19/git master. Can anyone using Neon Dev Unstable or the KDE unstable repo (or compiling stuff from source) verify?

works for me too.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.18.80
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.1

Thank goodness!

Using mouse wheel still works in desktop view but not in folder view.

Operating System: Manjaro Linux 
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.2
Kernel Version: 5.6.4-1-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4702MQ CPU @ 2.20GHz
Memory: 23,4 GiB

I have the same issue on FreeBSD 12.1:
QT 5.14.2
Plasma 5.18.4.1
Frameworks 5.69.0

According to comment #8 Plasma 5.19 should fix the issue and bring back the old behavior. Could someone please post a pointer to the change which brings the fix (and even better, also to the change which broke the behavior in the first place).

*** Bug 421001 has been marked as a duplicate of this bug. ***

*** Bug 420918 has been marked as a duplicate of this bug. ***

Broken for me in Fedora 32, plasma 5.18.5.

Workaround:

Right click desktop -> configure desktop -> Wallpaper -> layout -> desktop (was folder view). 

I can scroll again.

(In reply to Nate Graham from comment #8)
> This is working for me in Plasma 5.19/git master. Can anyone using Neon Dev
> Unstable or the KDE unstable repo (or compiling stuff from source) verify?

According to this comment, the issue should be fixed with plasma 5.19. However, for me it still persists:
- OS FreeBSD 12.1
- qt 5.14.2
- plasma 5.19.1
- frameworks 5.71.0

I am reopening this issue.

(In reply to Martin from comment #16)
> (In reply to Nate Graham from comment #8)
> > This is working for me in Plasma 5.19/git master. Can anyone using Neon Dev
> > Unstable or the KDE unstable repo (or compiling stuff from source) verify?
> 
> According to this comment, the issue should be fixed with plasma 5.19.
> However, for me it still persists:
> - OS FreeBSD 12.1
> - qt 5.14.2
> - plasma 5.19.1
> - frameworks 5.71.0
> 
> I am reopening this issue.

Similar setup for me but on Archlinux ~AMD64 with the latest patchset:
- Qt 5.15.0
- Plasma 5.19.1
- KDE Frameworks: 5.71.0

(In reply to Matt W from comment #15)
> Broken for me in Fedora 32, plasma 5.18.5.
> 
> Workaround:
> 
> Right click desktop -> configure desktop -> Wallpaper -> layout -> desktop
> (was folder view). 
> 
> I can scroll again.

Yes, the issue is that switching with folder view is broken which was once working. Deactivating folder view would at least mean that it should be made clear to the users that the mouse wheel switching is not supported in that mode.

*** Bug 417566 has been marked as a duplicate of this bug. ***

*** Bug 423402 has been marked as a duplicate of this bug. ***

I had this bug as well, but it seems to be solved with the latest release (5.19.4). Can anyone else confirm?

(In reply to Riccardo Robecchi from comment #21)
> I had this bug as well, but it seems to be solved with the latest release
> (5.19.4). Can anyone else confirm?

Nope, not fixed for me. Still same issue.

(In reply to Riccardo Robecchi from comment #21)
> I had this bug as well, but it seems to be solved with the latest release
> (5.19.4). Can anyone else confirm?

Just today I realized that I could scroll in Firefox while notification was showing. So it seems to be fixed for me as well. At least in Firefox.

Same problem with PCLOS/KDE 5.19.5, started after a big KDE update 3-4 months ago. Had previously worked fine. It does sometimes work IF the pointer hovers over the virtual desktops indicator, but more often I have to click to access the desired desktop.

Just installed Fedora/KDE on another system. Worked fine until after I updated it (full update last night). Now does not work, as described by others, and exactly as above.

*** Bug 427836 has been marked as a duplicate of this bug. ***

*** Bug 429359 has been marked as a duplicate of this bug. ***

*** Bug 432201 has been marked as a duplicate of this bug. ***

Still an issue in 5.21 beta. Something in FolderView seems to eat the scroll event

Looks like the scrollevent gets eaten in https://invent.kde.org/plasma/plasma-desktop/-/blob/master/containments/desktop/package/contents/ui/FolderView.qml#L634

Yep, I've been suffering from this for almost a year now. The only areas where mouse wheel switching still works is to the left and to the right of Latte dock (it is located on the bottom of my screen). This could be a hint for solution, hopefully.

Looked into this today and found that it's broken with Desktop view too.

When using a mouse, rolling the wheel by exactly one click makes the switch work properly, However rolling by 2 or more clicks makes the transition begin and immediately reverse itself. The effect is even easier on a touchpad because it doesn't have clicks, so it's harder to hit whatever magic number of accumulated scroll points is needed.

I'll see if I can find where the code for this lives and try to fix it.

This seems strongly related to navigation wrapping, which is also un-disable-able due to Bug 425787.

When wrap is on (as it's bugged to always be right now) a touchpad scroll goes "too far" due to Bug 369426 and wraps around, leaving you back on the same virtual desktop you started out in, creating a "bouncing" effect. This is extremely noticeable with only two virtual desktops. With three or more, the effect is less pronounced.

This is why it seems reproducible for some people, but not others: you only hit it all or most of the time when you only have two virtual desktops, with the root cause being Bug 425787. When you have more than two virtual desktops, that isue is replaced with the touchpad scroll threshold being too low to feel comfortable, due to Bug 369426.

So we have to fix three issues:
1. Make navigation wrap disable-able: Bug 425787
2. Require a larger touchpad scroll gesture to switch: Bug 369426
3. Discard "overscroll" that would take you back to the same virtual desktop you started at. Essentially wrap (when enabled) should only take effect if you were always on the first or last desktop and scrolled in that direction. That would be basically this bug report.

Lowering priority now that the wrap setting is respected, since people with only two virtual desktops can disable wrap to completely eliminate the problem.

I don't know where the idea comes from that this issue only occurs with two virtual desktops. I have been using four of them since ages, and it's since the release of Mageia 8 , using Plasma 5.20.4 that I also see this issue.

The issue is still present in 5.21.4 with 3, 4 or 5 desktops and no matter if wrap around is turned on or off.

With a sidebar that does not cover the entire edge of the virtual desktop, scrolling the mouse wheel in the area that is not covered by the sidebar works.

@Dr. Boris Neubert
Yep. The issue still persists. No idea why it is considered low priority now. Switching using mouse wheel or touchpad gesture is possible only if hovering over Pager applet or empty areas around Latte dock.

This is happening to me on a fresh install of Kubuntu 21.04 (KDE Plasma Version 5.12.4). No desktop switching when using scrollwheel on the desktop. It works if the mouse pointer is over the virtual desktop indicator widget in the bottom bar.

(In reply to Lisa Miller from comment #37)
> This is happening to me on a fresh install of Kubuntu 21.04 (KDE Plasma
> Version 5.12.4).

I hope you meant Plasma 5.21

I am also affected by this, please fix. Happy to provide any logs if needed.

KDE Plasma 5.23.5 on Debian Sid.

(In reply to Matt W from comment #15)
> Broken for me in Fedora 32, plasma 5.18.5.
> 
> Workaround:
> 
> Right click desktop -> configure desktop -> Wallpaper -> layout -> desktop
> (was folder view). 
> 
> I can scroll again.

This workaround still works as well

i'm fine with it. shall i close it?

If closing implies that this will never be mended in folder view, then no, don't close as far as I am concerned

I continue to not be able to reproduce the issue. If I can, I can try to fix it.

For the people affected, can you answer the following questions:
1. What Plasma version are you using?
2. How many virtual desktops do you have, and what is their arrangement?
3. Are you sure you're using Folder View for your desktop?
4. If so, do you have so many desktop icons that your desktop has become scrollable?

1. Plasma 5.20.4
2. 4 desktops in two rows
3. yes
4. there are 4 desktop  icons.

1. Plasma 5.22.5
2. 4 desktops in 1 row
3. yes
4. there are about 15 icons, desktop not scrollable

I have a tool bar at the left edge of the screen, in the middle, height approx. one fifth. Mouse-wheel scrolling works in the area the width of the toolbar that is not covered by the tool bar

1. Plasma 5.23.4
2. 2 desktops in 2 rows (so 1 desktop in each row)
3. Yes, I have folder view
4. Nope, only 5 icons

(In reply to Nate Graham from comment #43)

1. 5.23.5
2. 2 desktops in 1 row
3. Sure, because switching to Desktop view is the only workaround available to circumvent the issue except for another less convenient one.
4. There are just 4 icons on my desktop.

Regarding another workaround:
It is possible to use mouse scroll to change VD if mouse cursor is hovered over area occupied by Latte dock or Plasma panel. I have Latte in the bottom middle of my screen, there is a space to the left and to the right of it, where switching desktops with scrolling works. If I terminate Latte, switching desktops with scroll stops working.
I can roughly describe as follows: it feels like a there's a transparent layer on Plasma desktop in Folder mode that prevents using scroll to switch virtual desktops, but Latte and/or panels cut that layer to fit them in, and switching begins to work in space occupied by Latte and/or panels. Like "Folder View" is actually a "Desktop View" but with Folder View applet maximized, this is how it looks like.

Nope, not fixed for me.  Presently 5.23.5

Just noticed a second bug that I'd guess is really part of this one:

In Desktop view, sometimes once I right-click, only another right-click will get rid of the popup; left click is ignored. This is not consistent and went away after I'd tried it several times, as if some setting didn't get updated in a timely manner. It did NOT happen in Folder view.

For the people affected, can you answer the following questions: 

1. What Plasma version are you using? 
5.23.5

2. How many virtual desktops do you have, and what is their arrangement? 
Four, 2x2.

3. Are you sure you're using Folder View for your desktop? 
Yes. (Because Desktop view hides my icons, and then I'm like, WTF.)

4. If so, do you have so many desktop icons that your desktop has become scrollable?
I had no idea this was possible. Only 3 icons. (Normally I'd have a lot more, but this setup hasn't got there yet.)

1. Plasma version: 5.23.5
2. 4 virtual desktops, 1 row
3. Yes, I am sure I have selected "Folder View" in Desktop settings
4. I have no desktop icons at all (which is why the workaround suits me)

*** Bug 447158 has been marked as a duplicate of this bug. ***

Thanks for the info everyone. Unfortunately it doesn't help me figure out why I can't reproduce the issue. :(

Are any of you on Wayland? Or does the bug only manifest on X11, maybe?

(In reply to Nate Graham from comment #52)
> Thanks for the info everyone. Unfortunately it doesn't help me figure out
> why I can't reproduce the issue. :(
> 
> Are any of you on Wayland? Or does the bug only manifest on X11, maybe?

X11 here.

Feel free to ask for more info, logs, or command outputs - happy to share them.

Anyone able to reproduce on Wayland?

(In reply to Nate Graham from comment #54)
> Anyone able to reproduce on Wayland?

Fedora 32 KDE: working. 
Fedora 34 KDE: not working (noticed immediately after the upgrade from 32).
According to what I can find, Fedora 34 was when it switched the default to Wayland.

Fedora 35 KDE: Wayland. Initially not working. However, as of an update done a week or so back, it is now working on both Folder View and Desktop. (Just checked. This is not a daily driver.) But the desktop NAMES (displayed in middle of screen after switching) are truncated, so only the first 3 or 4 letters are visible, plus ellipses. Never seen that before. So instead of showing Air Earth Fire and Water, it shows Air Ear... Fi... and Wat...

PCLinuxOS KDE (rolling): X11. Was working until a few months back, now not working.

Thanks for the info. Unfortunately I still can't find a pattern or reproduce it on either X11 or Wayland. Maybe someone else can figur eout the pattern.

I have a current KUbuntu 21.10. I just added a new user for testing purposes with default settings. Then added 4 desktops in a row. It does not switch desktops when scrolling with the mouse wheel. Turning from folder view to desktop view makes the mouse wheel work. So it was easy to reproduce for me.

Only thing I can think off what could make a difference is the screen resolution: 3840x2160 60 Hz on a Samsung U28D590 connected via DisplayPort.

I volunteer to demonstrate it in a screen sharing session if that would help. My time zone is UTC+1

Back to the above:

Fedora is VGA and 1280x1024
PCLinuxOS is DVI-D and 1280x1024 
(different monitors)

another PCLOS setup on a 3rd monitor, DVI-I, was at 1920x1080 but lost its marbles and became stuck at 800x600. Either way, same problem: works in Desktop view, doesn't work in Folder View.

More info:

Have Bug: These are all within a minor revision of the same version.
PCLinuxOS, Fedora, Mageia
KDE Plasma version 5.23.5
kernel 5.15.14

Does not have Bug:
Debian
KDE Plasma version 5.14.5 (apparently borrowed from Mageia)
kernel 4.19.1-10

All tell me they're up-to-date.

Created attachment 148120 [details]
Screenshot showing areas of the screen where scrolling on the desktop switches virtual desktop

I installed Kubuntu LTS 20.04 where this bug was not present, then upgraded to 20.10 where this bug is present.

@Nate Graham:
1. What Plasma version are you using?
    5.22.5

2. How many virtual desktops do you have, and what is their arrangement?
    Four in a single column (ie four rows, one desktop per row)

3. Are you sure you're using Folder View for your desktop?
    Yes (scrolling works in Desktop view, but then you've no icons on your desktop, which make it an unsuitable workaround for me)

4. If so, do you have so many desktop icons that your desktop has become scrollable?
    No, just three icons on a 4k desktop, not scrollable

Can also confirm what others have said - scrolling on Latte dock works, and in the areas to either side of a dock if it is not full-width/height (see attached screenshot).

Comment on attachment 148120 [details]
Screenshot showing areas of the screen where scrolling on the desktop switches virtual desktop

UPDATE: Actually, the yellow box on the left is *not* scrollable, it's only the yellow boxes at the top and bottom that are

*** Bug 455250 has been marked as a duplicate of this bug. ***

*** Bug 456513 has been marked as a duplicate of this bug. ***

When I switch from folder layout to workspace layout (don’t know the English version), the workspace switching via mouse wheel does work again.

For anyone that needs a quick fix to this problem i suggest doing this:
1) Copy the folder org.kde.desktopcontainment from /usr/share/plasma/plasmoids/org.kde.desktopcontainment
2) Paste it inside $HOME/.local/share/plasma/plasmoids/
3) Open the file $HOME/.local/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderView.qml
4) Look for this line: Folder.WheelInterceptor {
5) Change the property from enabled: root.isContainment && !gridView.overflowing to enabled: true
6) Save the file
7) Restart Plasma and it should work ;-)

(In reply to André from comment #65)
> For anyone that needs a quick fix to this problem i suggest doing this:
> 1) Copy the folder org.kde.desktopcontainment from
> /usr/share/plasma/plasmoids/org.kde.desktopcontainment
> 2) Paste it inside $HOME/.local/share/plasma/plasmoids/
> 3) Open the file
> $HOME/.local/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> FolderView.qml
> 4) Look for this line: Folder.WheelInterceptor {
> 5) Change the property from enabled: root.isContainment &&
> !gridView.overflowing to enabled: true
> 6) Save the file
> 7) Restart Plasma and it should work ;-)

Waow thanks André it worked! What a relief!

@ André

This whole folder $HOME/.local/share/plasma does not exist here with Mageia 8 (long time KDE - Plasma user). So it looks like each user (Checked more than one) just uses the "default" in /usr/share/plasma/plasmoids/org.kde.desktopcontainment.
What do you recommend, changing the /usr/.... setting, or creating the folder structure manually in  $HOME/.local/share/???

@ Herman Viaene
Always create the folder structure manually in $HOME/.local/share/plasma/plasmoids/
Never change the files on /usr/share/plasma/plasmoids/ (this are the core files)

If you ever need to roll back just remove the folder you created inside $HOME/.local/share/plasma/plasmoids/org.kde.desktopcontainment

I believe this should be marked fixed, as the commit and "version fixed in" were updated in bug 419878 but not here.

@Andre
Finally got around doing the changes you proposed in Comment 65 and 68. Works OK, tx a lot.

*** This bug has been marked as a duplicate of bug 419878 ***