keyboard doesn't display in webapps after some time

[Bill Filler]

using build r48
maliit-framework 0.99.0+git20130615+97e8335-0ubuntu8
ubuntu-keyboard 0.99.trunk.phablet2+14.10.20140515-0ubuntu1
webapp-container 0.23+14.10.20140522.1-0ubuntu1

I don't have the exact steps to reproduce the issue, but have run into a lot over the last few days of using the phone.

- launch gmail webapp
- launch twitter webapp
- try and use both, doing things to cause the osk to display (like sending/replying to email, writing a tweet, etc)
- click on links in gmail that cause the browser to be open
- all works fine for a while
- then do other things on phone, like launch other apps, open the browser app, suspend resume, use the carousel spread to switch between open apps (fast right edge swipe)
- phone gets into a state where the osk is no longer displayed in the webapps no matter what you do

The only way to get osk back in the webapp is to close the webapp and relaunch it. This fixes the webapp you relaunched but not others that are already open.

[Bill Filler (bfiller)]

wondering if could be related to https://bugs.launchpad.net/ubuntu-keyboard/+bug/1306656

[David Barth (dbarth)]

It could be due to popup windows somehow stealing the focus of the main webview. I noticed OSK issues while debugging Gmail account switching, which triggers popup redirections.

[Olivier Tilloy (osomon)]

I am able to reliably reproduce with the following simple steps:

 1) launch the twitter webapp
      - log in
      - press the button to write a new tweet
      - tap in the text field to summon the OSK
      - input some characters
      - dismiss the screen by either posting the tweet or canceling and discarding it
 2) back at the tweet list, click on an external link in any tweet
      - this opens the link in the browser application
 3) swipe from the right edge to go back to the twitter webapp
      - press the button to write a new tweet
      - tap in the text field to summon the OSK

Expected result: the OSK shows up
Current result: no OSK

[Michael Sheldon (michael-sheldon)]

I'm now able to actually reproduce with even fewer steps, just opening twitter and visiting an external link, then swiping right is enough to trigger it. The keyboard doesn't even need to have been shown beforehand.

It seems oxide is sending visibility change requests correctly when the focused node changes, however the keyboard plugin never receives them, so I'm now taking a look at the maliit framework to try and work out what happens in between to cause the request to go missing.

Interestingly if the maliit-server is restarted after the bug has been triggered the keyboard will start displaying in the twitter webapp again.

[Chris Coulson (chrisccoulson)]

The workaround for this seems to cause a crash when running the unit tests if the window loses focus. I guess this will probably happen in the browser as well:

#0 0x00007fffc85eed25 in oxide::qt::RenderWidgetHostView::FocusedNodeChanged (this=0x10dedc0, is_editable_node=<optimised out>)
    at ../../../../qt/core/browser/oxide_qt_render_widget_host_view.cc:823
#1 0x00007fffca8b8cba in content::RenderViewHostImpl::OnFocusedNodeChanged (this=this@entry=0x2692550, is_editable_node=false)
    at ../../../../third_party/chromium/src/content/browser/renderer_host/render_view_host_impl.cc:1307
#2 0x00007fffca8c35a0 in DispatchToMethod<content::RenderViewHostImpl, void (content::RenderViewHostImpl::*)(bool), bool> (arg=..., method=
    (void (content::RenderViewHostImpl::*)(content::RenderViewHostImpl * const, bool)) 0x7fffca8b8c90 <content::RenderViewHostImpl::OnFocusedNodeChanged(bool)>, obj=0x2692550)
    at ../../../../third_party/chromium/src/base/tuple.h:548
#3 Dispatch<content::RenderViewHostImpl, content::RenderViewHostImpl, void, void (content::RenderViewHostImpl::*)(bool)> (sender=<optimised out>, parameter=0x0, func=
    (void (content::RenderViewHostImpl::*)(content::RenderViewHostImpl * const, bool)) 0x7fffca8b8c90 <content::RenderViewHostImpl::OnFocusedNodeChanged(bool)>, obj=0x2692550, msg=
    0x7fff8c06cc68) at ../../../../third_party/chromium/src/content/common/view_messages.h:1170
#4 content::RenderViewHostImpl::OnMessageReceived (this=0x2692550, msg=...) at ../../../../third_party/chromium/src/content/browser/renderer_host/render_view_host_impl.cc:998
#5 0x00007fffca8b17a1 in content::RenderProcessHostImpl::OnMessageReceived (this=0x2691e30, msg=...)
    at ../../../../third_party/chromium/src/content/browser/renderer_host/render_process_host_impl.cc:1416
#6 0x00007fffc8c7c9e2 in IPC::ChannelProxy::Context::OnDispatchMessage (this=0x10e19a0, message=...) at ../../../../third_party/chromium/src/ipc/ipc_channel_proxy.cc:273
#7 0x00007fffc867dedb in Run (this=0x7fffffffabb8) at ../../../../third_party/chromium/src/base/callback.h:401
#8 base::MessageLoop::RunTask (this=this@entry=0xda2890, pending_task=...) at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:450
#9 0x00007fffc867e921 in base::MessageLoop::DeferOrRunPendingTask (this=this@entry=0xda2890, pending_task=...)
    at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:462
#10 0x00007fffc8682185 in base::MessageLoop::DoWork (this=0xda2890) at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:576
#11 0x00007fffc85ee66a in oxide::qt::MessagePump::customEvent (this=0xd9e3f0, event=<optimised out>) at ../../../../qt/core/browser/oxide_qt_message_pump.cc:60
#12 0x00007ffff79c42ad in QObject::event (this=0xd9e3f0, e=<optimised out>) at kernel/qobject.cpp:1169
#13 0x00007ffff799befd in QCoreApplication::notify (this=<optimised out>, receiver=<optimised out>, event=<optimised out>) at kernel/qcoreapplication.cpp:943
#14 0x00007ffff799bc2d in QCoreApplication::notifyInternal (this=0x7fffffffd800, receiver=0xd9e3f0, event=event@entry=0x10f55e0) at kernel/qcoreapplication.cpp:881
#15 0x00007ffff799de07 in sendEve...

[Chris Coulson (chrisccoulson)]

Backed this out for now. Michael, would you mind taking a look at that crash please?