| Summary: | ApplicationWindow().overlay continues to block wheelEvents when a Popup is closed with a mouse click | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | elman <elman> |
| Component: | general | Assignee: | Marco Martin <notmart> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | kdelibs-bugs-null, nate, nsprangers |
| Priority: | NOR | ||
| Version First Reported In: | 5.81.0 | ||
| Target Milestone: | Not decided | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Diff for EntryScreenshots.qml | ||
|
Description
elman
2021-04-16 07:34:52 UTC
Also 8. Click Navigate back button 9. Mouse wheel scrolling in items list doesn't work either. Scrolling can be restored when I click on image again and use Esc key to close image. Hmm, cannot reproduce. I tried it on 2 different computers (another Manjaro and Arch) and I can reproduce it on both of them. I can confirm. Happens with anything that uses knewstuff. Scrollwheel function is restored by clicking any item then returning to the list. OpenSUSE Tumbleweed: KDE Unstable knewstuff: 5.86.0git.20210929T215207~de50a5a0-ku.11.1 Meant to add: X11 session Created attachment 142081 [details] Diff for EntryScreenshots.qml The issue seems to be that applicationWindow().overlay continues to block wheelEvents when the Popup (EntryScreenshots.qml) is closed with a mouse click. The bug is not present when: - hit escape to close the Popup - set `modal: false` - remove `parent: applicationWindow().overlay` - set `closePolicy: Popup.CloseOnEscape | Popup.CloseOnReleaseOutside` (attached diff) The default closePolicy would be Popup.CloseOnEscape | Popup.CloseOnPressOutside. The attached diff "fixes" the issue, but it seems like the default should work. https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html#closePolicy-prop I don't know enough about QML, so that's as far as I got. Nice investigation. I'm also not sure which would be the correct fix for this, but it would be best to find where the bug is somewhere in Kirigami so we don't need to add workarounds in code that uses it. |