Bug 344706 - KMenu won't show sometimes (multi-monitor setup)
Summary: KMenu won't show sometimes (multi-monitor setup)
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: 5.17.3
Platform: Arch Linux Linux
: NOR grave
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
: 346428 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-03-01 15:00 UTC by Alexander Nestorov
Modified: 2021-01-11 16:36 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Wrong position (657.44 KB, image/jpeg)
2015-03-24 08:33 UTC, Alexander Nestorov
Details
screenshot ofplasma problem (34.51 KB, image/png)
2015-07-12 07:20 UTC, Jaime Torres
Details
Launcher/Kmenu thing appearing on incorrect screen (1.55 MB, image/png)
2015-10-27 00:41 UTC, jamese
Details
Screenshot of K menu issue (1.43 MB, image/png)
2019-11-21 03:30 UTC, Alex
Details
Monitor Layout (69.39 KB, image/png)
2019-11-21 03:31 UTC, Alex
Details
Tray Popup Issue (2.27 MB, image/png)
2019-11-21 03:33 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Nestorov 2015-03-01 15:00:54 UTC
Sometimes, randomly based during an entire session*, KMenu just won't appear on any of the monitors in a multi-monitor setup. The button is in the panel, but when I click it, nothing happens. I can't see the applications menu anywhere.

*session == the entire session from booting to shutting down the computer. Which mean that I might boot the computer and there are two possible cases:

1) Kmenu  will always work (will always appear where it should appear), no matter how many times I click on it.
2) Kmenu won't appear even a single time.

When case 2, the only "workaround" is to reboot until I'm on case 1.

I'm setting this to grave because it actually prevents me from using my machine.


Reproducible: Sometimes
Comment 1 Alexander Nestorov 2015-03-01 15:01:14 UTC
Ah, also note that this was also happening in 5.2.0
Comment 2 Eike Hein 2015-03-01 15:07:36 UTC
Kickoff or Kicker?
Comment 3 Alexander Nestorov 2015-03-01 15:11:18 UTC
Which one is the default Kmenu that you get?
Comment 4 Eike Hein 2015-03-01 15:20:51 UTC
Kickoff.
Comment 5 Alexander Nestorov 2015-03-01 15:23:25 UTC
Kickoff is it then :)
Sorry for misguiding there, but KDE suffers from a really bad "what-is-this-thing-called" problem. There is no easy way to find out what is the name of quite a lot of KDE's components. But, oh well, I guess that is a whole different story/bug.
Comment 6 Alexander Nestorov 2015-03-24 08:33:15 UTC
Created attachment 91710 [details]
Wrong position
Comment 7 Alexander Nestorov 2015-03-24 08:34:52 UTC
As you can see this also happens when Kickoff is added as a widget on the desktop. And also, the tooltips have wrong position too, which makes me think this could not be a Kickoff issue, but rather a Plasma issue.
Comment 8 David Edmundson 2015-03-27 16:05:07 UTC
I can't reproduce this.
I even tried setting up virtual box to have 4 fake monitors.

Are there any clues that might help?

What version of Qt do you have?
What version of plasma-framework?

Are you able to self compile plasma-framework if I gave you some extra debug lines to add?
Comment 9 Alexander Nestorov 2015-04-09 20:56:38 UTC
Sorry for taking so long to reply...

I'm on KDE Frameworks 5.8.0,
KDE 5.2.2
Qt 5.4.1-3

Yes, I can take the patches you want and apply them, I just need a simple how-to that I can follow.
Also, please try to make only qDebug() changes as this is a workstation and I can't brake it.
Comment 10 Alexander Nestorov 2015-04-10 10:15:28 UTC
Since upgrading to 5.8.0 and 5.2.2 and Qt 5.4.1-3 I can reproduce this bug 100% of the time.
Comment 11 Alexander Nestorov 2015-04-10 18:47:10 UTC
You're gonna laugh on that one... 

It turns out I was  completely out of space on / 
Now, the weird part is that neither KDE or any other software warned me even once about that. I noticed it because I had to restart mongod and it failed at starting again.

Yeah, systemd's coredumps (autogenerate is ON by default) ruined a 256gb for /

Anyways, now KMenu opens just fine, which makes me wonder why does KMenu need any space on / to open in the first place? I mean... I'd understand if KDE itself failed to start because of some log failed creation, or anything else, but that is not the case, as KDE was running just fine, it was just KMenu that didn't show.

(Just to make it clear, I had my / completely full and yet I managed to reboot the entire machine several times just to test the KMenu "bug").
Comment 12 David Edmundson 2015-04-10 18:50:08 UTC
It should't.

I think this might just be co-incidence, or you just had a broken kbuildsysocococoa cache that hadn't been updated in ages.

keep an eye on this, I think it might well come back. Let us no if it does.
Comment 13 Alexander Nestorov 2015-04-22 21:10:08 UTC
Ok, it happened again.
Now I'm on KDE 4.14.7, 15.04.0, Qt 5.4.1-3

Instead of just rebooting until I got a working environment, I decided to play with it. It turns out the menu (and krunner) are *there* (somewhere), just that they are not visible. However, if I click Kmenu and then type something ("spotify" or "dolphin" for example) and then hit enter, it gets launched.

I managed to record a video of that: https://www.youtube.com/watch?v=LHskECyBgJc
(this is 4K, 4 monitors, 1080p each one)

As you can see in the video, I click the kmenu button then I type "spotify", then I hit enter and spotify gets launched. However, kmenu doesn't appear (nor krunner).

This might be either kmenu (and krunner) appearing somewhere outside my monitor's bounds (wrong position calculation?) or not being able to render because of some bug.

What do you think?
Comment 14 Alexander Nestorov 2015-04-26 09:05:57 UTC
I keeped working with the "broken" environment and eventually plasma crashed, so I started it again from shell and now both kmenu and krunner show fine.

This makes me think that the problem is indeed some incorrect position calculation caused by an out-of-time calculation because of how a 4 monitors setup works (it's slower to boot, maybe?)
Comment 15 David Edmundson 2015-04-28 10:05:43 UTC
I've added some debug into what will be the next frameworks release. So you can report back with

Till then could you try two things for me:

1) run with openbox and see if you still have the same issue


2) run 

kquitapp5 plasmashell
QSG_VISUALIZE=overdraw plasmashell

and see if you see the menu that time.
Comment 16 Christopher Bräuer 2015-05-09 14:29:36 UTC
I have the same bug on my system: the menu isn't shown, when I click on the K. Only the blue bar/separator is shown.
In my case, I had changed the way, new windows are opened. I don't know the english text, but it has to do with new windows and if the pop up in the foreground or not. I set this option to "high" and is caused the bug. When I set it back to "normal", the menu is shown again.
Maybe this helps.

Greetings!
Comment 17 Simone Gaiarin 2015-05-09 15:36:02 UTC
I have the same problem. The setting you mentioned is "Focus stealing prevention"? I have it set to Low but the problem is there.
Comment 18 Christopher Bräuer 2015-05-09 15:44:04 UTC
(In reply to Simone Gaiarin from comment #17)
> I have the same problem. The setting you mentioned is "Focus stealing
> prevention"? I have it set to Low but the problem is there.

Yes, that's the setting I ment.
In my case, it only happens with setting "high" or "extreme".
I use the newest Framework 5.3.
Comment 19 Simone Gaiarin 2015-05-09 17:12:58 UTC
My configuration:
Notebook + docking station and one external monitor
The KMenu is on the external screen (on the panel)

Running
    kquitapp5 plasmashell && plasmashell 
fix the problem.

If the notebook is undocked and docked again:
- First time I click on KMenu I see the menu appearing on the other screen
- Next times I don't see the menu anymore
Comment 20 Jaime Torres 2015-05-10 07:51:02 UTC
Using plasmashell 5.3.x from source (compiled with clang 6 from scratch yesterday)

It happens to me all the time...
My panel is at the top of the screen, I'm using Kicker.
If there is any application window, the menu appears and disaapears inmediately.
If all the applications are minimized, the menu appears normally.

If I kill plasmashell and restart it again, then the amount of application windows does not matter, the menu appears normally.
Comment 21 Simone Gaiarin 2015-05-10 08:41:48 UTC
In my case it not appears never, even with all windows minimized.
Comment 22 Jaime Torres 2015-05-10 09:12:03 UTC
It does not happen only to the menu, but also to other plasma widgets, like the calendar when pressed the clock in the panel.
Comment 23 Simone Gaiarin 2015-05-10 09:14:26 UTC
Yes and also to the tooltips.
Comment 24 Marco Martin 2015-05-12 11:37:53 UTC
*** Bug 346428 has been marked as a duplicate of this bug. ***
Comment 25 Bogdan 2015-05-12 11:45:06 UTC
(In reply to Marco Martin from comment #24)
> *** Bug 346428 has been marked as a duplicate of this bug. ***

My original posting about the bug also included an issue with the screen going black after detaching one of the monitors (only mouse cursor visible and movable, restart needed to fix the situation). I don't see this issue here and probably it's related.
Comment 26 Alf Mel 2015-06-05 03:43:07 UTC
I just upgraded to Plasma 5 in a new installation of Arch Linux. I am encountering this problem. For what I can see, the problem occurs when the second screen is primary. My setup is, laptop on the left, monitor via HDMI to the right, with the HDMI screen as primary. When using this configuration, the menu appears once to the left of the laptop screen. After that, the menu never appears. The System Tray pop-ups (like Clock, Clipboard, Mixer, etc) also behave erratically. Video driver is Intel, on Dell m3800.

Here is the xrandr command used to set up my screens:

xrandr --output eDP1 --mode 1920x1080 --left-of HDMI1 \
    --output HDMI1 --primary --mode 1920x1080

I could shoot a video of the behavior, if that would help.
Comment 27 Jaroslav Reznik 2015-06-22 07:45:52 UTC
I see the same issue with the external monitor set as primary (and on this second monitor only). It mostly works for Kicker but in 90% of time it happens with KRunner. After KRunner is invoked, window looses focus but KRunner is not visible. When I start typing, it's shown on incorrect internal monitor. Same happens with Kickoff, sometimes with tray. It's hard to explain it 100% correctly as it's a bit chaotic behavior. Btw. maybe it's even under Plasma 5.3 itself as for example it happens with Firefox popups too... On Intel, with one internal and two external outputs via DP.
Comment 28 Alf Mel 2015-06-23 03:44:13 UTC
(In reply to Jaroslav Reznik from comment #27)
> Btw. maybe it's even under Plasma 5.3 itself

Yes, the bug is still present int 5.3.x. That's what I'm running.
Comment 29 Bogdan 2015-07-08 07:58:06 UTC
(In reply to Alf Mel from comment #28)
> (In reply to Jaroslav Reznik from comment #27)
> > Btw. maybe it's even under Plasma 5.3 itself
> 
> Yes, the bug is still present int 5.3.x. That's what I'm running.

On Plasma 5.3, if I plug in the external monitor, Plasma cannot go past the login screen and restarts, asking for the password again and again. Other weird symptoms appear as well: sometimes, the laptop screen goes black and only about a quarter of the external screen is usable, until I open the monitor settings. The laptop screen seems to have been somehow switched off and instead of sitting next to the external monitor, I was moved at a random location. Somehow the multi-monitor support is completely broken. At least on Plasma 5.2, I had issues mostly with KRunner and when adding a new external projector.
Comment 30 Jaime Torres 2015-07-12 07:20:33 UTC
Created attachment 93572 [details]
screenshot ofplasma problem

Probably has something to do with this bug.
At some moment, the plasma panel got to this status:
* It is drawn like it is applying two styles at the same time.
* There is a dark block under the panel, where the previews of the tasks are shown (more or less).
Comment 31 Alf Mel 2015-10-25 16:02:12 UTC
Can someone change the version number on this bug to reflect that the problem exists in 5.4.x? This issue doesn't seem to be getting much traction and it has a noticeable impact on usability.
Comment 32 jamese 2015-10-27 00:41:33 UTC
Created attachment 95154 [details]
Launcher/Kmenu thing appearing on incorrect screen

Think I have the same thing, Kubuntu 15.10 / Plasma 5.4.2. See attachment.

The Menu /Launcher thing appears on the non-primary display always right aligned in the position shown
it also takes 3 clicks on the K to make it appear.

Note also the empty but inactive laptop screen on left as described here:
https://bugs.kde.org/show_bug.cgi?id=349482

If I toggle the primary display from right to left then back to right, as in that linked bug, the Launcher appears on the correct screen, with only one click to show it.
Comment 33 Ian Proudler 2016-01-03 18:02:11 UTC
For what it is worth, I have the same problem.

I have a desktop pc with two monitors. If I boot with the dual monitors activated, then the main panel is frozen e.g. the application launcher does not work, the tool-tips appear in random places if at all, the 'show hidden icons' button does nothing,  the 'usb device' button does nothing. Also 'Alt-F2' does not open the 'plasma search' window.

If I use one monitor, everything is OK.

I'm using Kubuntu 15.10. I have applied all 'apt-get' upgrades to date. 

uname -a ->
Linux Linux8 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

kded4-config -v ->
Qt: 4.8.6
KDE Development Platform: 4.14.13
kde4-config: 1.0

kf5-config -v ->
Qt: 5.4.2
KDE Frameworks: 5.15.0
kf5-config: 1.0
Comment 34 Ian Proudler 2016-01-03 18:09:25 UTC
I forgot to mention: If I boot using a single monitor and then switch to a dual monitor configuration, everything is OK. 
I have an 'application launcher' widget on the desktop. This always works.
If I boot using a dual monitor configuration, the main panel is frozen but I can use the 'application launcher' widget on the desktop to switch to a single monitor configuration and then everything is OK again.
Comment 35 Ian Proudler 2016-01-07 11:40:25 UTC
I have just been experimenting with some of the display settings. The compositor rendering backend  was 'OpenGL 2.0'. I changed it to  'OpenGL 3.1' and the problem appears to have gone away.
Comment 36 Simone Gaiarin 2016-01-07 12:48:47 UTC
I've tried to set OpenGL 3.1 and restart kwin (without rebooting the PC) and the problem is still present. 

Moreover I've seen that KRunner appears only on the notebook screen while it's invisible in the two external monitors.

I have an Intel graphic card.

Running Plasma 5.5
Comment 37 Jaime Torres 2016-08-07 21:11:15 UTC
I think I've found the probably cause of the problem (by pure chance). I usually have the option "Window Behaviour"|"Focus stealing prevention" in High and I suffer this bug. I've changed it to Medium and the problem is gone (The opened menu is there even with non minimized programs).

Please, someone else should check if this avoids this problem. If this workaround works, then this bug will be easier to fix.
Comment 38 Ian Proudler 2016-08-08 09:38:38 UTC
My "Window Behaviour"|"Focus stealing prevention setting has always been 'Low'.

However I have switched from using the default Application Launcher (described as "Launcher to start applications " in the 'add widgets' menu) to the alternative one (described as "A launcher based on cascading menus" in the 'add widgets' menu) . This always presents itself. However occasionally, on start up it will swap between the two monitors for half a second before settling on the wrong one.
Comment 39 Anguo 2017-05-22 00:29:46 UTC
I have the same problem but on a single monitor set up.
Clicking the K-menu, a blue bar appears on top of it, but the menu itself does not appear.
I solve it by doing:

$ killall plasmashell
$ plasmashell &
Comment 40 JonnyRobbie 2017-06-08 10:19:53 UTC
Yeah, coming here with the same problem. Multimonitor setup, KF 3.34.0, Qt 5.8.0, Plasma 5.10.0, 4.11.3-1-ARCH x86_64. The bug was there with high focus stealing prevention. Turning it down to medium seem to have fixed (or at least mitigated) the bug.
Comment 41 Alexander Mentyu 2017-12-05 16:49:28 UTC
Looks related to https://bugs.kde.org/show_bug.cgi?id=336134
Comment 42 Alex 2019-11-21 03:30:33 UTC
Created attachment 124040 [details]
Screenshot of K menu issue
Comment 43 Alex 2019-11-21 03:31:18 UTC
Created attachment 124041 [details]
Monitor Layout
Comment 44 Alex 2019-11-21 03:33:25 UTC
Created attachment 124042 [details]
Tray Popup Issue
Comment 45 Alex 2019-11-21 03:34:08 UTC
I have been experiencing this issue since kde 4 was deprecated by my distribution. The problem was generally intermittent for me up until the latest Plasma update (5.17.3).  Now the problem seems to be stuck in the borked state every time plasma starts.

I noticed some of you were having a hard time replicating this issue, so let me describe some of my observations.  This issue only seems to happen with two monitors of differing resolution.  I currently have a 4k monitor @30Hz and a 1k monitor @60Hz.  The 4k display is setup on the left of the 1k and is set to the primary display.  The smaller 1k on the right is setup where the bottom edges align, but the top of the smaller monitor starts below the top of the larger.  I have attached a screenshot for clarification.  In case it matters, I am using a Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] with the mesa drivers (19.3.0_rc3) and this is a Gentoo Linux machine.

I boot to a command line login and start X11 + Plasma with startx.  The plasma shell is initiated from ~/.xinitrc as `exec ck-launch-session dbus-launch --sh-syntax --exit-with-session "/usr/bin/startplasma-x11"`.  After plasma starts, I notice the following issues related to this bug: 

    1) Plasma Application Menu and tray expansion menu are offset as if they were calculated for position on the smaller 1k monitor.  The offset of both menus appears to be borked by about the same amount. Screenshots attached.

    2) Desktop Icons and Widgets are arranged as if the 4k monitor was only 1920x1080, but after Plasma starts I can rearrange the icons and Widgets.

I can resolve the issue in the following ways:

    1) Remove the power connector for either monitor, then startx.

    2) `kquitapp5 plasmashell; plasmashell`

My best guess as to what is happening is that one of the two monitors becomes available to Plasma before the other and Plasma just assumes that there is only 1 display.  This is problematic when the 1k display is the one detected first, as all of the correct ratios are in-place when the 4k is detected first.  Both displays are up and running when logging into the command line and are mirrored with the 4k display scaling down to 1k. I can only speculate that the display availability is effected by switching to OpenGL as X11 starts which is causing a race condition in Plasma's display detection.

A note on focus stealing prevention.  I have had my setting at low for a very long time, so I highly doubt that is the root cause of this issue.
Comment 46 Alex 2019-11-21 04:06:22 UTC
So, adding sleep to the .xinitrc before starting plasma doesn't have any effect but switching the HDMI cables between the two displays is producing consistently correct results for the time being.
Comment 47 Nate Graham 2021-01-07 19:06:22 UTC
Can you see if this is fixed with the new Kickoff UI in Plasma 5.21 (currently in git master)? A lot of this code was rewritten which means there's a chance it got fixed in the process.

Thanks!
Comment 48 Ian Proudler 2021-01-07 19:54:40 UTC
I have not had this problem for sometime now. I can't say when it was 'fixed' for me. 

I'm still using OpenGL 3.1 but since I've upgraded to Kubuntu 20.04 I'm back to using the default Application Launcher (described as "Launcher to start applications " in the 'add widgets' menu).
Comment 49 Jaime Torres 2021-01-11 09:47:35 UTC
I'm trying the new code and it works for me, after removing the kwin rule I use with the distributed plasmashell.
Comment 50 Nate Graham 2021-01-11 16:36:38 UTC
Cool, thanks for re-checking.