keyboard doesn't display in webapps after some time

Bug #1323743 reported by Bill Filler
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
High
Michael Sheldon
ubuntu-keyboard
Fix Released
Critical
Michael Sheldon
webbrowser-app
Fix Released
Critical
Michael Sheldon
ubuntu-keyboard (Ubuntu)
Fix Released
Critical
Michael Sheldon

Bug Description

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.

Tags: rtm14
Revision history for this message
Bill Filler (bfiller) wrote :
Changed in ubuntu-keyboard:
importance: Undecided → Critical
assignee: nobody → Michael Sheldon (michael-sheldon)
Changed in webbrowser-app:
importance: Undecided → Critical
Changed in ubuntu-keyboard (Ubuntu):
importance: Undecided → Critical
assignee: nobody → Michael Sheldon (michael-sheldon)
tags: added: rtm14
Revision history for this message
David Barth (dbarth) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Changed in ubuntu-keyboard:
status: New → Confirmed
Changed in webbrowser-app:
status: New → Confirmed
Revision history for this message
Michael Sheldon (michael-sheldon) wrote :

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.

Bill Filler (bfiller)
Changed in oxide:
status: New → In Progress
Changed in ubuntu-keyboard:
status: Confirmed → In Progress
Changed in webbrowser-app:
status: Confirmed → In Progress
Changed in ubuntu-keyboard (Ubuntu):
status: New → In Progress
Changed in webbrowser-app:
assignee: nobody → Michael Sheldon (michael-sheldon)
Bill Filler (bfiller)
Changed in webbrowser-app:
milestone: none → beta-freeze
Changed in oxide:
status: In Progress → Fix Released
milestone: none → branch-1.1
Revision history for this message
Chris Coulson (chrisccoulson) wrote :
Download full text (6.1 KiB)

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...

Read more...

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

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

Changed in oxide:
assignee: nobody → Michael Sheldon (michael-sheldon)
status: Fix Released → In Progress
importance: Undecided → High
Changed in oxide:
status: In Progress → Fix Released
Bill Filler (bfiller)
Changed in ubuntu-keyboard:
status: In Progress → Fix Released
Changed in webbrowser-app:
status: In Progress → Fix Released
Changed in ubuntu-keyboard (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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