| Summary: | Authentication dialog sometimes appears behind the window that requested it | ||
|---|---|---|---|
| Product: | [Plasma] policykit-kde-agent-1 | Reporter: | Aaron Williams <aaronw> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | agurenko, akostadinov, aldo-public, andrei.ilie, aspotashev, bugseforuns, claudius.ellsel, f.alexander.wilms, geqch0akc, ilikefoss, jan.molnar, jsthale, kde.org, kwin-bugs-null, luca76, mail, mashkal2000, mk.mateng, mlabakker, nate, rthomsen6, shimi.chen, shubham.chaudhary, sitter, spamless.9v5xj, testing1237a-c, uc |
| Priority: | HI | Keywords: | usability |
| Version: | 5.21.4 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=433485 https://bugs.kde.org/show_bug.cgi?id=141267 https://bugs.kde.org/show_bug.cgi?id=460730 https://bugs.kde.org/show_bug.cgi?id=469398 |
||
| Latest Commit: | https://invent.kde.org/plasma/polkit-kde-agent-1/commit/239ec8537b88f57ec1366b4121d14a4655581ac9 | Version Fixed In: | 5.27.5 |
| Attachments: | Here is a temprary fix in the form of a window rule | ||
|
Description
Aaron Williams
2012-12-29 02:53:10 UTC
Moving back to policykit as there is not much KWin could do about it. The behavior by KWin is absolutely correct. A random popup opens and of course the focus stealing prevention blocks such dangerous attempts. The password dialog needs to provide the relevant information to let KWin know that the dialog opens due to a user request. Any news on this ? It is still happening in 4.10.1. add a rule for that window (pw dialog) and set the focus stealing prevention to "none" as workaround. Still happening in 4.11.3 with polkit-kde-agent-1-0.99.0. This bug should be fixed as it has been around for a long time. *** Bug 269876 has been marked as a duplicate of this bug. *** *** Bug 330380 has been marked as a duplicate of this bug. *** I do not know about this whole "focus prevention" subsystem, but there is another annoyance related to this problem. When I want to manage a root process from the "CTRL+ESC" manager, the password dialog opens under it. As I have set my to appear in center, I have thus guarantee that it will always start invisible. I understand that it is a result of strict appliance of multiple rulesets. However, for the sake of polished experience something has to be done. One idea that I have that would need no change to rules is to display the password dialog as part of the program; in the existing window; on top of user interface; not spawn it in a new window. And make it part of the Interface Guidelines, so that application developers write accordingly. > something has to be done https://git.reviewboard.kde.org/r/124130/ > to display the password dialog as part of the program; in the existing window a) that would be technically close to impossible, since they stem from different processes b) if that was done, one could just mark it as transient for that window (the proper solution*) itfp. c) if you propose apple sheet-a-like dialogs to the HIG group, they'll likely hang, draw and quarter you :-P * the challenge for kwallet here is often that there's no window from the calling client - it would likely work for ksysguard, but not at all for akonadi (the mailclient daemon) Let's try c) - I want to see that happen! http://www.zdnet.com/article/things-that-suck-somewhat-mac-os-x-sheets/ https://sixcolors.com/post/2014/11/attack-of-the-50-foot-save-sheet/ Best invention ever. Right after drawers: http://www.mcelhearn.com/the-mac-os-x-drawer-a-badly-designed-user-interface-element/ Sorry for the late reply - I was very busy with my work. I am not a programmer, so I do not know much about how this stuff is implemented. This is why what I thought was a neat idea is practically impossible to realise. What I can see now is that there is a bunch of programs that handle password entry. How about having them become a widget in plasma? Though, the widgets are XML or HTML, right? This does not sound right after all. Maybe a plasma widget that notifies that a password window has opened and calls it up to front, when clicked? (In reply to Paśnikowski Marek from comment #11) > Maybe a plasma widget that notifies that a password window has opened and calls it up to > front, when clicked? Nothing of this can fix for the general "issue" - unless ekither a) the PW dialog (can be) correctly marked transient for it's mainwindow (the application that needs the password) OR b) enforces activation OR c) the focus stealing prevention approach in KWin is altered (to separate focus and full raise permissions), it really doesn't matter how, when, where or why the dialog is triggered. The problem is *longtime* known, I wrote a small essay on "why focus handling needs to be improved" and the kwin patch addresses this. Impho a) the clients (in this case the PW dialog) are "broken", because they keep valuable information "secret" from the WM b) KWin should better be able to handle that (beyond rules), since the official NETWM behavior is actually to let every client steal any focus anytime. Ie, despite you'd really not like to deactivate the FSP mechanisms, it's still a KWin *feature* that needs to be "less" invasive in finding a good cut between the NETWM spec and aggressively interfering clients. > it's still a KWin *feature* that needs to be "less" invasive in finding a good cut between the NETWM spec and aggressively interfering clients.
What I had been thinking about: should we maybe first only roll out the new behavior for Wayland clients? On the one side we don't have any focus stealing prevention for them yet (and that sucks bad time, my test drive yesterday afternoon nearly drove me crazy over that), on the other side we don't risk regressions for the current user base.
Does wayland have sufficient client relation hints? (The FSP largely relies on them, the patch is just an amending modification) How big is the wayland userbase? Can we expect more (and better) feedback than from general betas? (Otherwise one could simply push that into betas and iff it turns out to be regressive* revert it for the release) *the major regression in the approach might be bug #337798 - by design (iff the client starts up really fast) The "problem" here is that one mans feature is another mans bug. If you're typing into a texteditor - or even konsole - you do not want another window to get the focus, just because you can only do 40 or less keystrokes per second, allowing another client to steal the focus between two strokes. Dedicated runners could either withdraw or reset the usertime to guarantee passing the focus to the upcoming client (otoh, it's not clear whether the user is not about to launch the next client in a row...) Other than this, I don't expect additional issues - the usual complaint is that dialogs "start behind" and the patch will lower this (but not eg. allow a mapping maximized window to completely stash the focused window) > Does wayland have sufficient client relation hints? (The FSP largely relies on them, the patch is just an amending modification) Good in application. Not at all cross-applications (which is a problem for things like kwallet and policykit [1]) > How big is the wayland userbase? Can we expect more (and better) feedback than from general betas? Probably not. Though it would allow to have it tested for a longer time, e.g. a complete release cycle instead of just a few weeks during beta. [1] I hope that will create enough pain that people will finally come up a solution for this. *** Bug 312885 has been marked as a duplicate of this bug. *** For me on Fedora 34 the issue is with Wayland only. X11 is fine. I notice this with kwallet and password entry for encrypted hard drives. -- polkit-kde-5.21.4-1.fc34.x86_64 I am noticing this too on Kubuntu 21.10. For instance with Balena Etcher or KDE Partition Editor. Password dialog hides behind application. Operating System: Kubuntu 21.10 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-28-generic (64-bit) Graphics Platform: X11 Processors: 6 × AMD Ryzen 5 3500X 6-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: Radeon RX 580 Series Using click to focus. Unbelievable that this bug dates back to 2012! *** Bug 407592 has been marked as a duplicate of this bug. *** *** Bug 420786 has been marked as a duplicate of this bug. *** https://youtu.be/6-fkYFV7rOY?t=230 watch this 22 year old video of steve jobs explaining mac os save panels and panels in general. maybe we can take some inspiration from this? i understand the current bug is about password dialog boxes but still is a good idea to look at imo I can confirm that this is still an issue with 5.24.5, but only with a few select applications. In general it works as expected for me. Notable exception is KDE Partition Editor. I guess the problem here is that the application itself is not positioned according to the window positioning rules, but opened centered on the screen, thus hiding the also centered auth dialog. I don't see a reason for KDE Partition Editor to have its window opened centered. It should behave like all other applications as well. I guess as soon as this is changed, the polkit dialog will work as well. Alternatively, the incorrect window positioning could also be caused by KDE Partition Editor requesting authentication immediately when started. A possibly relevant merge request was started @ https://invent.kde.org/plasma/polkit-kde-agent-1/-/merge_requests/14 Created attachment 153091 [details]
Here is a temprary fix in the form of a window rule
*** Bug 467321 has been marked as a duplicate of this bug. *** Can I please get an updated list of which applications you are seeing this problem with and whether you are seeing it on x11 or wayland? (Please test with latest versions only, that includes plasma). I'd also be very interested in video recordings of this happening. For the record: for partitionmanager in particular my theory is that there is a race condition between the two windows appearing (i.e. the mainwindow only appears after the auth window), which would explain why the stacking order is incorrect despite us calling forceActiveWindow in the auth dialog code. Personally I have only ever seen this with Partition Manager. It isn't 100% reproducible for me though. Maybe 1 in every 10 times it happens. Maybe an easy to reproduce example. KDE: 5.27.4 KDE Framework: 5.104.0 X11 When I click on the network connection and choose to connect to a VPN (or I guess whatever network where password is not remembered), then an auth dialog pop up but input is not received until the menu is closed with a mouse click. And this is very annoying especially for VPNs that use 2fa so password can't be saved. I just remembered that I'm pretty sure I recall seeing this happen at some point with the Firewall KCM (on Wayland, don't know about X11) when enabling or disabling the firewall. I can't reproduce it right now, of course... (In reply to Harald Sitter from comment #26) > Can I please get an updated list of which applications you are seeing this > problem with and whether you are seeing it on x11 or wayland? (Please test > with latest versions only, that includes plasma). > > I'd also be very interested in video recordings of this happening. > > For the record: for partitionmanager in particular my theory is that there > is a race condition between the two windows appearing (i.e. the mainwindow > only appears after the auth window), which would explain why the stacking > order is incorrect despite us calling forceActiveWindow in the auth dialog > code. The resion that the window only sometimes show up at the top is because when you open a window it shows up above all other windows with partition manager the main window loads after polkit is called, so it appears behind to fix this have the polkit window have the keep above all windows flag set I did that with the window rule but if that can get integrated in to the kde polkit agent that would fix this. A possibly relevant merge request was started @ https://invent.kde.org/plasma/polkit-kde-agent-1/-/merge_requests/23 Can reproduce with balena Etcher after click on 'Flash!' button. https://www.balena.io/etcher#download-etcher Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland Git commit 239ec8537b88f57ec1366b4121d14a4655581ac9 by David Edmundson, on behalf of Harald Sitter. Committed on 02/05/2023 at 11:10. Pushed by davidedmundson into branch 'Plasma/5.27'. force extreme focus protection this should help with all cases of the auth dialog not having focus. with extreme protection nothing should be able to automatically steal focus from the auth dialog. user input is still respected same as before though M +11 -0 main.cpp https://invent.kde.org/plasma/polkit-kde-agent-1/commit/239ec8537b88f57ec1366b4121d14a4655581ac9 *** Bug 429770 has been marked as a duplicate of this bug. *** *** Bug 460730 has been marked as a duplicate of this bug. *** This bug is still reproducible with Partition Manager and balena Etcher on Wayland session of Plasma 5.27.5. Can anyone else confirm? (In reply to Patrick Silva from comment #36) > This bug is still reproducible ... on ... 5.27.5. IMO there are two different bugs. 1) Dialog displayed behind a window (logged as this ticket) and 2) dialog displayed on top, but not focused (started in Plasma 5.27). I logged bug 469398 for the latter one. (In reply to Patrick Silva from comment #36) > This bug is still reproducible with Partition Manager and balena Etcher on > Wayland session of Plasma 5.27.5. > Can anyone else confirm? Yes. Balena Etcher. Plasma 5.27.4 on X11. (In reply to Patrick Silva from comment #36) > This bug is still reproducible with Partition Manager and balena Etcher on > Wayland session of Plasma 5.27.5. > Can anyone else confirm? As far as I understand it's not fixable on wayland right now. We can't steal focus on wayland and because polkit API has no way to declare transient parents, kwin has no way of knowing that the dialog relates to another parent window. This ought to ultimately get resolved by a redesign of the auth dialog to not be a lonely dialog but instead become a fullscreen interruption dialog similar to the logout dialog. We have that on the radar for Plasma 6. *** Bug 478013 has been marked as a duplicate of this bug. *** |