This feels like a workaround to the actual issue itself. Why don't the context menus appear in the right place automatically? That seems like something that KWin is responsible for.

In D19535#425287, @ngraham wrote:

This feels like a workaround to the actual issue itself. Why don't the context menus appear in the right place automatically? That seems like something that KWin is responsible for.

The origin of the issue is that on a fresh new dolphin window on the left screen QCursor->pos() returns always QPoint(0,0) which is not correct.

After some more testing I discovered that once I switch the window to the other screen and back, the cursor position can be correct sometimes or has different bad position (not (0,0)), and on the other screen the cursor position con be become incorrect as well.

Also I wrote this code this way based on PlacesPanel::slotItemContextMenuRequested which is not affected by the same bug.

I am not sure this is a KWin bug.

The QCursor::pos() according to the documentation :

Returns the position of the cursor (hot spot) of the primary screen in global screen coordinates.

https://doc.qt.io/qt-5/qcursor.html#pos

But in a multi-screen context, this should not be used because it can't handle secondary screen as documented, which is the case here.
If that is the problem's root it also means that any use of QCursor::pos() will cause a bug in multi-screen contexts.
What do you think @ngraham KWin ?

In D19535#428339, @elvisangelaccio wrote:

This is not a KWin bug. QCursor::pos()} is not reliable on Wayland and should not be used.

Could we document this ? So that the community avoids discovering a horde a bugs once wayland usage grows. Maybe on https://community.kde.org/Plasma/Wayland_Showstoppers

Or maybe QCursor::pos() will be fix down the line, which I doubt since it would be an Qt API change.

Do you have commit access?

I don't have commit access.

Just in kdevelop I have a bunch of bugs I could report in similar situation :
https://github.com/KDE/kdevelop/search?q=Qcursor%3A%3Apos&unscoped_q=Qcursor%3A%3Apos

Thanks @ngraham

My pleasure. :)

In D19535#429447, @meven wrote:

In D19535#428339, @elvisangelaccio wrote:

This is not a KWin bug. QCursor::pos()} is not reliable on Wayland and should not be used.

Could we document this ? So that the community avoids discovering a horde a bugs once wayland usage grows. Maybe on https://community.kde.org/Plasma/Wayland_Showstoppers

Better on https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes (where we already explain how to avoid similar bugs).

In D19535#432739, @elvisangelaccio wrote:

In D19535#429447, @meven wrote:

In D19535#428339, @elvisangelaccio wrote:

This is not a KWin bug. QCursor::pos()} is not reliable on Wayland and should not be used.

Could we document this ? So that the community avoids discovering a horde a bugs once wayland usage grows. Maybe on https://community.kde.org/Plasma/Wayland_Showstoppers

Better on https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes (where we already explain how to avoid similar bugs).

I've added a note about context Menus and QCursor::pos() :
https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Context_Menu
Thanks :)