Bug 354309 - Don't take focus when showing device notifications
Summary: Don't take focus when showing device notifications
Status: RESOLVED NOT A BUG
Alias: None
Product: plasmashell
Classification: Plasma
Component: Disks & Devices widget (show other bugs)
Version: 5.4.1
Platform: Other Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-10-24 15:40 UTC by Bernd Steinhauser
Modified: 2020-11-28 19:49 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
mklapetek: Usability+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Steinhauser 2015-10-24 15:40:58 UTC
When inserting a device (i.e. switching an external drive on or inserting a USB stick), the device notification applet will pop up and show information about the new device, which is fine.
However, when doing so, the applet also takes the keyboard focus away from the current application requiring the user to manually switch back to the previous one.

As I use LUKS for my external devices and plasma (currently) doesn't always work too well combined to that, I tend to use udisk from within konsole.
Taking the keyboard away from the current app could be discussed if it would actually be useful, but it isn't. I can't navigate to the entry I want to use and start the desired action (the keys can be used for navigation, but not to select).
As most users will use the device notifier using a pointing device, I would therefore suggest to avoid taking the keyboard focus to not interfere more than necessary.

Reproducible: Always

Steps to Reproduce:
1. Start an application that uses the keyboard (i.e. kwrite or konsole), ensure it has focus
2. Start/insert a device that will result in a device notification


Actual Results:  
Notice that you can't type within the previously started program anymore. Notice that you can't do anything useful with the keyboard in the applet.
Notice that you either have to use the application switcher or the pointing device to get back to your application. The escape key won't take you back either.

Expected Results:  
Depends. I would expect it to not interfere at all and just display the notification.
If the keyboard should be usable within the applet, it should be done properly allowing to select entries (with the enter/return key) and exit (esc).
Comment 1 David Edmundson 2015-11-29 15:29:48 UTC
Right, but:

in the general case when people plug in a USB device they *do* want to immediately use it and so keyboard focus makes sense.

I'm not breaking that for an edge case. Would 351592 cover your needs?
Comment 2 Bernd Steinhauser 2015-11-29 21:37:42 UTC
Sure, that's ok as well.

And as I said, I do understand that people might actually want to use the keyboard to navigate. However, it does not work. When I tried right now it didn't work at all. Last time I tried before, I could navigate (as written above), but not select/activate.
So at least for me, it seemed already broken and thus the request.
Comment 3 Martin Klapetek 2015-12-04 20:36:27 UTC
> in the general case when people plug in a USB device they *do* want to immediately use it and so keyboard focus makes sense.

I'm not so sure about that. I mean that users would want to use it using keyboard. It actually never even occurred to me that I can/should use a keyboard. Imo it should be an announcement "you have inserted this device". If you want to react, you can use the mouse.

Let's see what the usability folks think.
Comment 4 Andrew Crouthamel 2018-09-25 21:57:55 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Andrew Crouthamel 2018-10-27 03:38:22 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bernd Steinhauser 2018-10-27 08:11:50 UTC
I don't see this solved. It wasn't in NEEDSINFO because of info you guys requested by me, but just because your usability department failed on commenting on the topic.
afaics, the behavior did not change at all, since I reported it, hence I don't see this as being resolved.
Comment 7 Patrick Silva 2019-03-01 22:43:22 UTC
(In reply to Bernd Steinhauser from comment #6)
> I don't see this solved. It wasn't in NEEDSINFO because of info you guys
> requested by me, but just because your usability department failed on
> commenting on the topic.
> afaics, the behavior did not change at all, since I reported it, hence I
> don't see this as being resolved.

Which plasma version are you using?
I can continue typing in the kate text editor after the notifier appears in plasma 5.15.2, Arch Linux.
Comment 8 Bernd Steinhauser 2019-03-03 09:34:16 UTC
(In reply to Patrick Silva from comment #7)
> Which plasma version are you using?
> I can continue typing in the kate text editor after the notifier appears in
> plasma 5.15.2, Arch Linux.
Same version here, 5.15.2 on Exherbo Linux, but the bug remains, exactly like I described above.
Maybe Arch applies some patches to fix that, I don't know.
Exherbo doesn't patch the sources for functionality, so it shouldn't be a distro-specific bug.
It might also be that you have focus stealing prevention active, which I don't.
(System Settings -> Workspace -> Window Management -> Window Behaviour -> Focus stealing prevention)

IMO the way it is (on my system at least) is pretty stupid, as it takes away focus but not in a way that you can do anything useful with it.
If it takes focus (which IMO it really shouldn't) then you would at least be expected to do anything useful with the keyboard, e.g. using the cursor keys to select an entry.

That's why the usability team was added, but apparently they don't care.
Comment 9 Nate Graham 2020-11-25 01:23:41 UTC
Am I understanding that you turned off focus stealing protection? What's it set to? "None"?

I've set the bug status to "needsinfo" pending your response. Please change back to "reported" or "resolved" when you respond, thanks.
Comment 10 Bernd Steinhauser 2020-11-25 20:43:05 UTC
(In reply to Nate Graham from comment #9)
> Am I understanding that you turned off focus stealing protection? What's it
> set to? "None"?
> 
> I've set the bug status to "needsinfo" pending your response. Please change
> back to "reported" or "resolved" when you respond, thanks.

I experimented a lot with focus stealing prevention, from "None" to "High".
Here in this case, "Low" will be sufficient to suppress the focus stealing.
I ended up turning the focus stealing prevention off though, since it sometimes results in undesired effects with some applications (would need to try it to get some examples, since it's been a while since I digged into this), like pop-ups or dialogs in applications not gaining focus.

However, my main argument against the current behavior is actually a different one.
While personally I think the focus stealing is annoying, others could see that differently *if* it was useful for *anything*, but it isn't.
It steals focus, but there is – afaics – nothing you can do.
I could understand, if you could e.g. select an action for a drive to be mounted using the cursor keys and enter or select a program to be used with the device, but that does not seem to be the case.

btw. the annoyance is even higher, because you can't just get back to your program (e.g. Konsole) by pressing Alt+Tab once, instead you have to do it twice, because the task switcher will first switch to a different program.
(Possibly because the device notifier is not enlisted as a program in it?)
Comment 11 Bernd Steinhauser 2020-11-27 10:01:02 UTC
(In reply to Bernd Steinhauser from comment #10)
> I experimented a lot with focus stealing prevention, from "None" to "High".
> Here in this case, "Low" will be sufficient to suppress the focus stealing.
> I ended up turning the focus stealing prevention off though, since it
> sometimes results in undesired effects with some applications (would need to
> try it to get some examples, since it's been a while since I digged into
> this), like pop-ups or dialogs in applications not gaining focus.

I do now remember what made me mainly drop the focus stealing prevention from my settings:
if it's activated, even at "Low" setting, programs activated by clicking on a systray icon (e.g. wallet manager or akregator) sometimes do not raise to the top and do not gain focus, but will open up in the background, which is highly annoying, because they were activated explicitly on my request.
This doesn't happen every time, but often enough to make me get rid of the focus stealing prevention.
Comment 12 Nate Graham 2020-11-28 19:49:07 UTC
I'm afraid if you turn focus stealing prefention to off, focus will sometimes get stolen. That's why the focus stealing prevention feature exists and why it's set to Low by default. :)

Now, to a certain extent, the feature is a band-aid/workaround for misbehaving apps. However it's not possible to fix all apps, and it's also not clear that immediately focusing the popup when it appears is incorrect, since once keyboard nav is fixed, it will be possible to navigate it with the keyboard in this situation.
> if it's activated, even at "Low" setting, programs activated by clicking on a
> systray icon (e.g. wallet manager or akregator) sometimes do not raise to the
>  top and do not gain focus, but will open up in the background,

This is probably Bug 423857. Once we fix that, you'll be able to turn focus stealing prevention back on. In the meantime, you'll have to live with one bug or another, sorry. :)