Issues with menu appearing on opposite side of screen after clicking on the start button

[alex-mao]

I'm currently running Debian Testing with LXQT has my desktop environment. I have noticed that there are times with clicking on the start button the menu will actually appear on the opposite side of the screen (example: taskbar is located on the bottom of the screen the menu will appear on the top). The resolution for this appears to be going into the configuration and changing where the taskbar is located, applying this and then reverting it back to the bottom and once again saving it.

If it is of any help again I am on Debian Testing running version 0.10.0 of LXQT with a QT version of 5.5.1.

From a conversation with someone on the #LXDE main chat channel on IRC this was a known issue but appears that it was never fully resolved so I am re-submitting the bug report in hopes that it will fully patched/corrected in later versions.

[tsujan]

You mean that, with one panel at the bottom, the main menu is shown at the top? What's the role of taskbar in this? A screenshot of your panel, please?

[alex-mao]

tsujan: It's the main/primary panel at the bottom, from a MS Windows perspective it's just the taskbar. The package name should be lxqt-panel. As this happens at random getting a screen shot may not be as easy but once it happens again I'll update with one.

[agaida]

@tsujan - it was a known bug back in 0.8 or 0.9 i guess - didn't heard of it for a while - i don't know who and when worked on this issue - maybe @paulolieuthier or @palinek can remember :P - i will have a look at our closed bugs meanwhile.

[agaida]

https://bugs.launchpad.net/ubuntu/+source/lxqt-panel/+bug/1528730 - that was the last time i see this bug

[pmattern]

You're probably talking about something like this (GIMP artwork)

right?

We've briefly discussed this in #508 (comment). It has indeed been a long-standing issue and probably a dedicated bug report didn't exist so far as it was so difficult to reproduce. It wasn't limited to plugin-mainmenu but affecting e. g. the GUI (left-click) of plugin-volume and the context menu of third-party application meteo-qt as well. I for one haven't seen it since quite a while running latest master checkouts on Arch Linux.
Maybe it has been silently fixed and we should wait until 0.11 is out and packaged by Debian before tracking this further.

[tsujan]

Strange! I came to LXQt about a year ago and have never encountered such an issue with Intel, nviidia or nouveau -- whether under Debian or under Manjaro. Last year, Debian experienced a series of very bad transitions, which caused several issues; this one could be one of them.

However, the LXQt theme I use doesn't style panel menus. So, if this still happens with the latest sources, it might have something to do with stylesheets.

[tsujan]

Moreover, there's a Qt5 bug (QTBUG-47043), because of which, _NET_WM_WINDOW_TYPE is set to _NET_WM_WINDOW_TYPE_NORMAL for QMenu. There's a workaround for it in Kvantum -- and I've never used LXQt without Kvantum.

[palinek]

I remember the problem with misplaced menus on multimonitor setup (mirroring, but different resolution). For mainmenu I believed this was fixed here ... lxqt/lxqt-panel@642e0ed7. Another commit dealing with correcting the position of menus lxqt/lxqt-panel@29b96a3c

So we realy need more info about your monitor setup @alex-mao.

[alex-mao]

@pmattern That's exactly what I've seen. Thank you for the screen shot.

@palinek It's a single monitor setup running at 1680x1050 (Brand: Samsung Model: GH22WS) and in case it's relevant:

• Video: Intel i915 version 1.6.0 20160229
• Controller: Intel Corp. 82G33/G31 Express integrated Graphics Controller (rev 02)

Let me know if you need anything else.

[palinek]

Let me know if you need anything else.

Exact steps to reproduce 😄 ... now we can just guess what's happening.

[jsm222]

It happens occasionally on my system as well. More often after a killed X-server.

[agaida]

i know that it is only a wild guess - but if we see this more often now this might have to do with Qt 5.6.1 - on thing speeks against it - i have really not touched the packages in sid and testing in this regard for a long time - ok, there was a transition in sid, but as long Qt 5.6.1 is not in testing this should have no effects.

[tsujan]

There are many unknown factors in reports:

(1) Which version and distro?
(2) Which compositor (Compton, KWin,...)?
(3) Does it happen without compositor?
(4) Which widget style (Fusion, Breeze,...)?

[stefonarch]

I just noticed the same on the laptop of my daughter, official arch packages, qt 5.0.6 (running pacman -Syu just now), no compositor installed, openbox, widget style fusion but changing does not matter.

[jsm222]

I did some gdb work..

[Switching to Thread 80f806400 (LWP 101397/lxqt-panel)]
A failed postioned instance:

Breakpoint 1, ILXQtPanelPlugin::calculatePopupWindowPos (this=0x80f8da090, 
    windowSize=@0x7fffffffd318) at ilxqtpanelplugin.h:185
185         return mPanel->calculatePopupWindowPos(this, windowSize);
(gdb) output mPanel->calculatePopupWindowPos(this, windowSize)
{x1 = 0, y1 = 0, x2 = 201, y2 = 441}(gdb) 

Notice the y1 , its zero for some to me unkown reason. Any thoughts?
Versus a working instance

(gdb) output mPanel->calculatePopupWindowPos(this, windowSize)
{x1 = 0, y1 = 591, x2 = 193, y2 = 1017}(gdb) 

[tsujan]

@stefonarch
Does it happen to you too (in case you use LXQt)? If not, what's the difference between the two settings?

@ everyone
If you've never experienced this issue, please tell about your settings, especially compositor and widget/panel style!

@jsm222
I suspect that the WM may consider the menu as a normal window (because of QTBUG-47043) and try to put it at the "right" place. Just a guess.

[alex-mao]

@tsujan I'm not running a compsitor (though Compton is installed just not set to start at login). As for widget style I am using Fusion

[jsm222]

@tsujan I have investigated your guess a little. Killing openbox does not correct the problem. The second thing is that xwininfo only shows one difference - the geometry - of the two scenarios.
lxm1 is xwinfo -all on a correct placed menu, and lxm2 is the same for the top. (The problem is still only periodic. but annoying..) There are no wm hints on the menu.

lxm1.txt
lxm2.txt
diff lxm1 lxm2

8c8
<   Absolute upper-left Y:  606
---
>   Absolute upper-left Y:  0
10c10
<   Relative upper-left Y:  606
---
>   Relative upper-left Y:  0
25,26c25,26
<   Corners:  +0+606  -1718+606  -1718-32  +0-32
<   -geometry 202x442+0-32
---
>   Corners:  +0+0  -1718+0  -1718-638  +0-638
>   -geometry 202x442+0+0
57c57
<       Process id: 17544
---
>       Process id: 17405
60c60
<       User supplied location: 0, 606
---
>       User supplied location: 0, 0
67d66
< 

Im running FreeBSD 10.3-RELEASE #0 r297264
openbox-3.6_1 and qt-5.5.1 Widgetstyle Fusion.
commit 433343ed27929dd50e74c4f24e5e8baf5f99cfaa

[stefonarch]

I did some testing, updating to qt 5.6.1-2 did not change behaviour.
It happens always after cold boot, killing panel and restarting solves, also restart session solves. Reset settings does not change anything. Strange is that on my laptop still with arch packages 32bit there is no issue. Only difference I can guess of that on my system compton is in use, so I installed compton on the other laptop and this issue disappeared. Hope this helps...

[tsujan]

There are no wm hints on the menu

If there were, they wouldn't work for Qt5 menus.

@alex-mao's, @stefonarch's settings have openbox + no compositor in common. @jsm222, could you use kwin or openbox+compton for a while and see if it happens again?

@stefonarch
The above-mentioned Qt5 bug isn't fixed yet, not even in v5.6.1. I don't know how compositors could work around it.

[stefonarch]

Just for testing I cold booted in my laptop with compton disabled and the issue did not appear, no logic in that.

[tsujan]

Just for testing I cold booted in my laptop with compton disabled and the issue did not appear, no logic in that.

And in the meantime, I cold booted my older computer with Openbox+Fusion+(default panel theme) but without Compton and could see no issue at all!

[palinek]

Can anyone, who is able to reproduce the behaviour, test with branch null_warn -> the commit lxqt/lxqt-panel@0f4694705900 ?

If the problem appears... does the newly added warnings appear in ~/.xsession-errors / systemd's journal?

[stefonarch]

I'm not able to reproduce it anymore now on both laptops, even removing compton hte problem does not reappear so I can't test for now.

[jsm222]

I saw this comment . And I have not been able to reproduce / experienced the error since switching from dual graphics cards to one singe graphics card, with a singe GPU. So it might come down to QT as stated in that comment.

[palinek]

OK... closing for now.

[pmattern]

Hm. So far we're only supposing the problem is due to QTBUG-47043, falling back to systems featuring a single GPU is a workaround but not a solution.
Isn't this a bit early to close then? Closed bugs tend to be not found by users running into the same issue.

@palinek
Did I get this right that branch null_warn / commit lxqt/lxqt-panel@0f4694705900 are intended to trigger a warning when the problem gets manifest only but not as fix?

[palinek]

Did I get this right that branch null_warn / commit lxqt/lxqt-panel@0f46947 are intended to trigger a warning when the problem gets manifest only but not as fix?

Yes, that should only help to find the problem. It is not a patch for this issue.

[pmattern]

Did I get this right that branch null_warn / commit lxqt/lxqt-panel@0f46947 are intended to trigger a warning when the problem gets manifest only but not as fix?

Yes, that should only help to find the problem. It is not a patch for this issue.

Thanks for clarifying. Shouldn't we just merge then? If there are no downsides like crashes or other nasty things this could help tracing this problem down. In particular as it's so bad to reproduce and running that branch long-term doesn't really make sense. Once the problem is fixed we can still remove that single commit again easily.

[pmattern]

While I haven't seen this problem since ages on Arch Linux it seems to be 100% reproducible running ISO image 2017-01-19 of the upcoming Fedora LXQt Spin (Qt 5.7.1, LXQt latest point releases 0.11.x) in a KVM/QEMU virtual machine.
Here it is affecting all panel widgets of LXQt like e. g. plugin-mainmenu

or plugin-taskbar

but only the first session after booting. It ceases after login out and in again. Also, the context menu of Qlipper is affected while the menu coming up on left click isn't. The image is (so far...) using the GTK panel widget of NetworkManager the context menu of which isn't affected either.

@palinek
This makes me once more wonder whether we shouldn't merge lxqt/lxqt-panel@0f46947 in order to track this problem, which apparently still exists, further down.

[palinek]

This makes me once more wonder whether we shouldn't merge lxqt/lxqt-panel@0f46947 in order to track this problem, which apparently still exists, further down.

done in lxqt/lxqt-panel@777bb52b

[aginiewicz]

I've had same problem on fresh Arch install - after changing lxqt-panel to be on top, applying and then to be back on bottom - it started working (even after restart). Maybe some defaults are incorrect or something?

[RecklessProcedure]

Some details that may help ya'll on this issue. It's happening on my LFS system. I've built everything myself and this happens to all menus after the first startup. It doesn't matter if it's started from an already active XSession or by a display manager.

The most unusual thing happened the first time I tried to to move the panel to the top, then bottom as is suggested here as a fix. When I selected "top of screen" from the drop down menu the first time, and only the first time, the task bar did not move at all.

The issue disappears after I move the taskbar to the right or left side of the screen. But before this is done, the taskbar will not move from the bottom to the top and all menus appear at the top. So, it seems that the top and bottom are represented by the same information before moving this panel to the right or left.

Is it possible there's an off-by-one in property iteration somewhere? I'm not familiar with C++, but this looks just like what happens in other languages when the first property in a collection gets skipped because I had setup the iterator incorrectly. i.e. Everything behaves as if two objects are controlled by a single property.

[dbungert]

I have reproduced this. About 10% of the time for me, panel will be in this state. With the code in lxqt/lxqt-panel@0f46947 in my build, I find that it is not a plugin lookup problem. Rather, the call from LXQtPanel::calculatePopupWindowPos() to panel_plugin->mapToGlobal() is yielding a (0, 0) point. panel_plugin->widget()->mapToGlobal(QPoint(0, 0)) is no better. Any suggestions?

[jsm222]

https://github.com/lxde/lxqt-panel/blob/85b532485d97a9d4ffa477218911b46f1c0998cd/panel/lxqtpanel.cpp#L1092 I mentioned this earlier, but I believe it is a QT bug.

[dbungert]

Thanks for the feedback @jsm222, I missed that. I will investigate the qt angle - QTBUG-48396 seems a likely candidate.

[dbungert]

I have a partial workaround - https://github.com/dbungert/lxqt-panel/tree/position. It is a workaround because mapToGlobal() is still in a bad state. It is partial because there are still references to mapToGlobal() / mapFromGlobal() that I have not yet addressed. But it may be sufficient for people who see this issue.

[palinek]

@dbungert can you, please, test/review the lxqt/lxqt-panel#440? It is a follow-up of your investigation with the mapToGlobal().

[dbungert]

@palinek Yours is a superior implementation. It works for me. I will subject your version to a loop test and report back.

[dbungert]

@palinek lxqt/lxqt-panel#440 works for me, passed my 10000 loop test.

[NobodyIII]

Can we get this released soon? I had the problem in with LXQt on Debian in VirtualBox a few minutes ago. I haven't seen it the past couple times I tried to reproduce it, but I wouldn't be surprised if it happened again later.

[palinek]

Can we get this released soon? I had the problem in with LXQt on Debian in VirtualBox a few minutes ago.

FYI it's already included in debian experimental/unstable/testing, but won't be backported to current stable (stretch).