Keyboard stays on screen after leaving an application

[Andrea Bernabei]

Krillin, rc-proposed/bq-aquaris.en, r388

Between today and yesterday it happened twice that the keyboard did not hide after switching away from an application.

The first time I think maliit crashed, I could interact with the system but the keyboard was unresponsive. I have no other info to provide on this, unfortunately.

The second time I was writing a message on Telegram, then I swiped away to get to the switcher and the keyboard did not hide. At that point I dismissed the keyboard by dragging it out of the view (top to bottom drag).

This is what I think is the unity8.log excerpt for the "second" case, i.e. swiping away from telegram and then hiding the keyboar while I was inside the switcher: http://pastebin.ubuntu.com/20043016/

Unfortunately I have no other details to report...

I'd say there is a regression somewhere in between r386 and r388

phablet@ubuntu-phablet:~$ sudo apt-cache policy unity8
[sudo] password for phablet:
unity8:
  Installed: 8.12+15.04.20160711-0ubuntu1
  Candidate: 8.12+15.04.20160711-0ubuntu1
  Version table:
 *** 8.12+15.04.20160711-0ubuntu1 0
        100 /var/lib/dpkg/status
phablet@ubuntu-phablet:~$ sudo apt-cache policy ubuntu-keyboard
ubuntu-keyboard:
  Installed: 0.99.trunk.phablet2+15.04.20160615.1-0ubuntu1
  Candidate: 0.99.trunk.phablet2+15.04.20160615.1-0ubuntu1
  Version table:
 *** 0.99.trunk.phablet2+15.04.20160615.1-0ubuntu1 0
        100 /var/lib/dpkg/status
phablet@ubuntu-phablet:~$ sudo apt-cache policy maliit-framework
maliit-framework:
  Installed: 0.99.1+git20151118+62bd54b-0ubuntu5vivid4
  Candidate: 0.99.1+git20151118+62bd54b-0ubuntu5vivid4
  Version table:
 *** 0.99.1+git20151118+62bd54b-0ubuntu5vivid4 0
        100 /var/lib/dpkg/status

[Daniel d'Andrada (dandrader)]

Those revision numbers are useless. Just flashed my krillin with:
ubuntu-device-flash touch ubuntu-system --channel ubuntu-touch/rc-proposed/ubuntu
Revision number is 535.

If you wanna give us reference points, package versions would work perfectly.

[Daniel d'Andrada (dandrader)]

Or dates even

[Daniel d'Andrada (dandrader)]

Can't reproduce it.

unity8 blindly obeys the OSK surface state. unity8 will show it as long as it is live and its state is visible (as in not minimized or hidden. If maliit crashed, unity8 would dismiss the surface.

There's nothing particularly interesting in that unity8.log. unity8 doesn't log OSK surface state.

If you still see this issue sometimes but not enough to provide good steps on how to reproduce it, I guess the only way forward is for you to run a custom unity8 with debug logging specific for tracking this issue.

[Daniel d'Andrada (dandrader)]

On 19/07/2016 17:28, Daniel d'Andrada wrote:
> I guess the only way forward is for you to
> run a custom unity8 with debug logging specific for tracking this issue.

I would provide that, naturally.

[Daniel van Vugt (vanvugt)]

I don't think those revision numbers are "useless". Revisions 386 and 388 do exist:
http://system-image.ubuntu.com/ubuntu-touch/rc-proposed/bq-aquaris.en/krillin/

So you just need to be sure you're flashing with the same channel and device, and use --revision=X to select which one.

[Daniel van Vugt (vanvugt)]

Incidentally I did warn that bugs like this could and would happen when we added maliit support for Xmir apps. The shell should still provide a failsafe 'hide-the-OSK' feature upon switching apps if the requisite 'hide' message never came through from the app.

[Andrea Bernabei (faenil)]

Thanks @vanvugt

@dandrader: the revision numbers are not useless, if you have enough parameters.

I provided everything but the channel suffix, giving for granted that you'd use bq-aquaris.en, which is the official BQ channel (I think that makes more sense over using the ubuntu channel).
Starting from that info you can get the packages versions you need.

Next time I'll make sure to also specify bq-aquaris.en.

If you want packages versions, please provide the list of packages you need versions of.

I added a few packages versions to the description

[Daniel d'Andrada (dandrader)]

On 20/07/2016 05:46, Andrea Bernabei wrote:
> @dandrader: the revision numbers are not useless, if you have enough
> parameters.
Let me rephrase then: they are useless unless you say exactly which
channel you used (pasting command line used is the best approach).
Device name and rev number are not enough. Every channel+device
combination have their own revision number. Because you need so much
information besides the rev number, that's why I think they're useless