Release nonsticky keys on keyboard hide

Bug #1648543 reported by Tony Crisci
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Onboard
Fix Committed
Undecided
Unassigned

Bug Description

Hi,

I have an application where a keypress may cause my application to use the dbus interface to hide the keyboard. In this case, the keyboard key that causes the hide will remain pressed when the keyboard is hidden. I think this is because it never gets the mouseup that would cause the keyrelease, but I'm not sure.

Specificially this is a web application where tab can shift browser focus to a non-text input element which causes the keyboard to hide for usability.

If I use a call to `release_pressed_keys()` after a `set_visible(False)` on the Keyboard class, it releases the key properly, but this is not a complete solution.

I am willing to work on this to resolve the issue faster.

What approach would you recommend for solving the issue?

Thanks.

Related branches

Revision history for this message
Tony Crisci (tonyctl) wrote :

This patch resolves the issue for me.

Revision history for this message
marmuta (marmuta) wrote :

Thank you. This is really something that can happen in regular usage as well. I believe however, that rather than letting the keyboard reach this unexpected state and clean up by force-releasing keys, we should better prevent that situation from happening in the first place. I think hiding the window should be delayed until all keys are released.

There already exist pause/resume and freeze/thaw functions in AutoShow.py. The former are meant for longer periods of time, e.g. for auto-hide on key-press, the latter for shorter durations, to skip over erratic auto-show behavior. However, neither remembers the most recent auto-show state, i.e. keyboard visible or not, and applies it afterwards (on resume, thaw), which is what we would need here. Adding that to freeze/thaw might be risky - perhaps there should be a third set of functions, say delay/apply.

If you would like to work on this please do. I'll merge it.

Changed in onboard:
status: New → Confirmed
Revision history for this message
marmuta (marmuta) wrote :

Fixed in trunk, I believe. The changes were a bit more involved than I described above, mainly due to bug #1366421, but the idea is still to delay the visibility change until all keys are released. Seems to work well here.

I'll ask Francesco for a snapshot. If you can, please wait for revision >=2207 to appear at
https://launchpad.net/~onboard/+archive/ubuntu/snapshots
and test it with your setup.

Changed in onboard:
status: Confirmed → Fix Committed
Revision history for this message
Francesco Fumanti (frafu) wrote :

I just uploaded revision 2207 of trunk for xenial, yakkety and zesty to the Snapshots PPA. It should be available soon. The packages for trusty and precise will probably follow tomorrow.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.