https://bugs.kde.org/show_bug.cgi?id=453532
Oded Arbel <o...@geek.co.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|dolphin-bugs-n...@kde.org |kio-bugs-n...@kde.org
Product|dolphin |frameworks-kio
Component|general |Places
CC| |k...@privat.broulik.de,
| |kdelibs-b...@kde.org
Version|22.08.1 |5.101.0
--- Comment #7 from Oded Arbel <o...@geek.co.il> ---
Correction: I *can* reproduce this issue with Dolphin, and also with Gwenview,
K3b - so it isn't a Dolphin issue.
The problem appears to be with kio's KFilePlacesView
(https://invent.kde.org/frameworks/kio/-/blob/master/src/filewidgets/kfileplacesview.cpp#L1077)
that creates the places context menu without a proper parent (possibly other
filewidgets suffer from the same issue - I think K3b uses a widget that isn't
KFilePlacesView).
I tried to fix this locally in Dolphin by setting the parent widget in the
`contextMenuAboutToShow` signal handler, but I didn't get much success with
that (I either can't find a valid parent, I'm doing something wrong or at this
point it is too late anyway).
BTW: for repro, you don't need a maximized window - it is easy to repro with
any app that uses a KIO file widget: after opening the app and making sure the
tested file widget is showing, activate another app that does not overlap the
tested area, then right click the tested widget. Because the right-clicked app
does not have an active window, and the menu has no parent, Qt fails to
associate the menu correctly and it displays as a top level window.
I have found a tangentially related old Qt bug that discusses some of the issue
- https://bugreports.qt.io/browse/QTBUG-60932 - that specific use case was
fixed in Qt 5.9, but as noted in that reports' comments - there's a more
general issue that wasn't fixed in Qt.
--
You are receiving this mail because:
You are watching all bug changes.
