Bug 772344

*** Bug 860506 has been marked as a duplicate of this bug. ***

Still valid with 13.1 accoding to bug 850813

*** Bug 860506 has been marked as a duplicate of this bug. ***

I can confirm this here on 13.1 (KDE:Current).

And those upstream bug reports seem related:
https://bugs.kde.org/show_bug.cgi?id=280422
https://bugs.kde.org/show_bug.cgi?id=293617
https://bugs.kde.org/show_bug.cgi?id=313021

So not an openSUSE specific problem I would say.

I found out something:
Setting the option "GrabInput=Always" in /usr/share/kde4/config/kdm/kdmrc (in the "[X-*-Greeter]" section) fixes the input focus issue in KDM completely, not only for the root password dialog, but also for the remote login dialog.

We could make this the default, but the comment says:
# Whether to grab keyboard and mouse while the greeter is visible. Grabs
# may improve security, but make on-screen keyboards, etc. unusable.


Anyway, I think I managed to fix the focus problem for the non-GrabInput case as well.
Please stay tuned for packages to test... ;)

Packages with my fix are available here:
http://download.opensuse.org/repositories/home:/wolfi323:/branches:/OBS_Maintained:/kdebase4-workspace/

Or, if you use KDE:Current:
http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Current/

Please test them (without setting "GrabInput=Always") and tell me whether they work or whether there are any problems.
Thank you!

You only need to install the updated kdm package...

Thanks Wolfgang!

Referring to https://bugs.kde.org/show_bug.cgi?id=338018

A) - Fixed.

B) - Fixed.

C) - Fixed.

D) - Depends. If the mouse pointer is within the remote login popup window, alt-xx are accepted and work fine. If the mouse pointer is elsewhere on the screen all keyboard input is ignored. Even if it was intended I think it is undesirable. There are no other windows, there is no window manager, and the pointer having to be within the "popup" area unexpected and confusing.

Switching back and forth between local and remote logins works fine.

I used http://download.opensuse.org/repositories/home:/wolfi323:/branches:/OBS_Maintained:/kdebase4-workspace/openSUSE_12.3_Update/x86_64/kdm-4.10.5-1.125.1.x86_64.rpm

I won't be able to test on 13.1, but I can test on 13.2 once I have upgraded sometime during the holidays.

Thanks for testing!

(In reply to Volker Kuhlmann from comment #7)
> D) - Depends. If the mouse pointer is within the remote login popup window,
> alt-xx are accepted and work fine. If the mouse pointer is elsewhere on the
> screen all keyboard input is ignored. Even if it was intended I think it is
> undesirable. There are no other windows, there is no window manager, and the
> pointer having to be within the "popup" area unexpected and confusing.

Yes, focus follows the mouse.
But that's normal behavior when no window manager is running. Just kill kwin in a KDE session and you'll see the same.

I don't think there's a way around that other than grabbing the input completely (for that you have the GrabInput=Always option, see comment 5).

But before, the "windows" could not get focus at all (although they seemed to have focus), now they should correctly get focus when you move the mouse over them, and the focus state is shown correctly as well. So at least you should see that the widget has no focus and it should accept the input if it looks like it has the focus.

> I won't be able to test on 13.1, but I can test on 13.2 once I have upgraded
> sometime during the holidays.

I don't think that's necessary. kdm hasn't changed at all in years (this problem is caused by a change in 4.4 from 2009 btw, where they decided to make input grabbing optional: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6). 
Unless I made a mistake in packaging the patch should work the same there as well.

For the record, I did some testing myself with onscreen keyboards, xvkbd and kvkbd in particular. My patch didn't change anything regarding their behavior, here are my exact findings:
- Without GrabInput, none of them work, the currently focussed widget looses focus as soon as you move the mouse to the OSK. But xvkbd has a "Focus" button, with which you can force to focus to a particular widget, this works perfectly then (with and without my patch). kvkbd doesn't offer anything like this though, AFAICS.
- With GrabInput, xvkbd doesn't work at all, just as the option's comment indicates. You cannot click on any of its buttons. Strange enough, kvkbd works perfectly in this case.

As I wrote in comment 5, we could also (maybe in addition to this patch) make GrabInput=Always the default, but I'm not completely sure about this.
Any opinions?

(In reply to Wolfgang Bauer from comment #8)
> Yes, focus follows the mouse.
> But that's normal behavior when no window manager is running. Just kill kwin
> in a KDE session and you'll see the same.
> 
> I don't think there's a way around that other than grabbing the input
> completely (for that you have the GrabInput=Always option, see comment 5).

By looking at xvkbd's source code (in particular what it does when you press the "Focus" button), I actually did find a way to prevent the dialogs from loosing focus when you move the mouse... ;)

New packages are up at the same locations, please re-test!

There shouldn't be any noticeable difference between GrabInput on or off now any more.

I also tried xvkbd and kvkbd again, _both_ work fine now without GrabInput. And you don't even need to use xvkbd's "Focus" button any more...

Thanks Wolfgang, you're brilliant. Thanks also for making the testing easy (providing packages and saying which minimum needs to be installed, that really helped).

Re D): In kdm it would be "focus strictly under mouse", not "focus follows mouse", either can be set for the desktop. The difference is that the window does not lose focus with the latter when the mouse is moved onto the desktop and no window is under the pointer. That really ought to be the behaviour for kdm too?

For me the change with GrabInput caused years of aggrevation with non-functional KDE software. As you say, "yes" was the behaviour until 2009. Setting that to "no" annoyed all normal keyboard users while allowing a minority to use on-screen keyboards. I say it's a minority because I had never heard of such things being available for kdm. I am certain my use cases will always be "yes", so would personally favour that default.

It all comes down to communication. How do you tell users to change option never-heard-of in file never-needed-to-touch-that? (Not this bugzilla...)

Have verified on openSUSE 12.3 and openSUSE 13.1 using http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Current/
that your fix works very nicely.

Using the first solution (kdm-4.11.14-7.1.x86_64.rpm) the password (or remote host) window loses focus, when the mouse pointer is moved outside the window frame.
Using the second solution (kdm-4.11.14-10.1.x86_64.rpm) the window keeps focus, no matter where the mouse pointer happens to be, just like you have explained.

Any idea as to when this very nicely working fix will be official available for KDE Current on openSUSE 12.3, 13.1 and 13.2?  And for KDE itself?

Thanks for the feedback!

(In reply to Volker Kuhlmann from comment #10)
> Re D): In kdm it would be "focus strictly under mouse", not "focus follows
> mouse", either can be set for the desktop. The difference is that the window
> does not lose focus with the latter when the mouse is moved onto the desktop
> and no window is under the pointer. That really ought to be the behaviour
> for kdm too?
No. That is a kwin feature to offer different focus options.
But on the login screen no window manager is running at all.

And there are no "windows" really anyway, just modal dialogs.

> For me the change with GrabInput caused years of aggrevation with
> non-functional KDE software. As you say, "yes" was the behaviour until 2009.
> Setting that to "no" annoyed all normal keyboard users while allowing a
> minority to use on-screen keyboards. I say it's a minority because I had
> never heard of such things being available for kdm. I am certain my use
> cases will always be "yes", so would personally favour that default.

It was not the default that has been changed. In the past KDM unconditionally grabbed the input completely. In 2009 this has been made optional, with the default set to "IfNoAuth", which means: "grab if the display requires no X authorization"

Regarding on-screen keyboards, I did know that they exist, but I didn't know how to use them with kdm. I had to google that.
It's not exactly straight-forward, i.e. you cannot just enable them in the settings, you have to run them in /etc/X11/xdm/Xsetup. This is explained in kvkbd's manual though.

> It all comes down to communication. How do you tell users to change option
> never-heard-of in file never-needed-to-touch-that? (Not this bugzilla...)

Well, this should not be needed any more with my patch.
I just mentioned that option here as an immediate workaround for users that are affected, and it might have been a possible "fix" to change the default.

I only discovered this option myself because I looked at the source code, although it is of course present in the shipped kdmrc (including the documentation I cited earlier).
But regarding to the discoveribility of that option, better complain to KDE... ;)

(In reply to Dennis Olsson from comment #11)
> Any idea as to when this very nicely working fix will be official available
> for KDE Current on openSUSE 12.3, 13.1 and 13.2?  And for KDE itself?

I created submit requests for KDE:Current and KDE:Distro:Factory, the fix will be in those repos as soon as those are accepted by the maintainers, and in Tumbleweed a few days later.
An openSUSE maintenance update normally takes about a week until it is released, if nothing goes wrong.

I'll try to push the patch upstream to KDE, but I cannot give a time frame for that. As the latest release has been yesterday, this will take at least a month though of course.

@Maintenance team: Is it ok to do an online update?

feel free to submit an update

(In reply to Wolfgang Bauer from comment #12)

> No. That is a kwin feature to offer different focus options.
> But on the login screen no window manager is running at all.

Yes I realise both of those facts, I used the kwin behaviour to describe what was happening. With your second test package the dialog doesn't lose mouse focus any more even if the mouse is moved, so thumbs up for that. I only tested with GrabInput= commented out.

Remote logins are working fine again so big thanks Wolfgang.

(In reply to Matthias Grießmeier from comment #14)
> feel free to submit an update

Done: https://build.opensuse.org/request/show/265919


(In reply to Volker Kuhlmann from comment #15)
> Yes I realise both of those facts, I used the kwin behaviour to describe
> what was happening. With your second test package the dialog doesn't lose
> mouse focus any more even if the mouse is moved, so thumbs up for that.

Yes, but as I said that's Xorg's standard behavior when there's no window manager running, nothing to do with kdm. Try to kill kwin in a KDE session and you'll see exactly the same.

But I do think that this "focus follows mouse" policy doesn't make sense on the login screen. There are not different windows between you might want to switch, only the modal dialogs. That's why I tried to "fix" this as well. ;)

Btw, kdm did activate the dialogs (by calling QWidget::activateWindow()), but for some reason this didn't give input focus. This might be seen as a bug in Qt I suppose. Not even calling QWidget::setFocus() helped though.
I'm now calling Xlib's XSetInputFocus() instead which works nicely, and keeps the focus even when the mouse is moved out of the dialog.

> I only tested with GrabInput= commented out.

Good, because with "GrabInput=Always", my patch is not even used (and it's not needed anyway)...
 
> Remote logins are working fine again so big thanks Wolfgang.

Hm? My patch doesn't change anything regarding remote logins.

It was of course not possible to use keyboard shortcuts and enter a hostname on the remote login screen, and you couldn't even login locally any more afterwards because you couldn't enter the password.
Is that what you mean? This should be fixed now of course, yes.

Update released for openSUSE 12.3, 13.1 and 13.2 - resolved fixed

openSUSE-RU-2015:0035-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 772344
CVE References: 
Sources used:
openSUSE 13.2 (src):    kdebase4-workspace-4.11.14-9.1
openSUSE 13.1 (src):    kdebase4-workspace-4.11.12-123.1
openSUSE 12.3 (src):    kdebase4-workspace-4.10.5-1.123.1

*** Bug 848606 has been marked as a duplicate of this bug. ***

*** Bug 744661 has been marked as a duplicate of this bug. ***