keyboard doesn't display in webapps after some time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Oxide |
High
|
Michael Sheldon | ||
| ubuntu-keyboard |
Fix Released
|
Critical
|
Michael Sheldon | |
| webbrowser-app |
Fix Released
|
Critical
|
Michael Sheldon | |
| ubuntu-keyboard (Ubuntu) |
Critical
|
Michael Sheldon |
Bug Description
using build r48
maliit-framework 0.99.0+
ubuntu-keyboard 0.99.trunk.
webapp-container 0.23+14.
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.
Related branches
- Chris Coulson: Approve on 2014-06-26
-
Diff: 16 lines (+6/-0)1 file modifiedqt/core/browser/oxide_qt_render_widget_host_view.cc (+6/-0)
Bill Filler (bfiller) wrote : | #1 |
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 |
David Barth (dbarth) wrote : | #2 |
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) wrote : | #3 |
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 |
Michael Sheldon (michael-sheldon) wrote : | #4 |
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.
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) |
Changed in webbrowser-app: | |
milestone: | none → beta-freeze |
Changed in oxide: | |
status: | In Progress → Fix Released |
milestone: | none → branch-1.1 |
Chris Coulson (chrisccoulson) wrote : | #5 |
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::
at ../../.
#1 0x00007fffca8b8cba in content:
at ../../.
#2 0x00007fffca8c35a0 in DispatchToMetho
(void (content:
at ../../.
#3 Dispatch<
(void (content:
0x7fff8c06cc68) at ../../.
#4 content:
#5 0x00007fffca8b17a1 in content:
at ../../.
#6 0x00007fffc8c7c9e2 in IPC::ChannelPro
#7 0x00007fffc867dedb in Run (this=0x7ffffff
#8 base::MessageLo
#9 0x00007fffc867e921 in base::MessageLo
at ../../.
#10 0x00007fffc8682185 in base::MessageLo
#11 0x00007fffc85ee66a in oxide::
#12 0x00007ffff79c42ad in QObject::event (this=0xd9e3f0, e=<optimised out>) at kernel/
#13 0x00007ffff799befd in QCoreApplicatio
#14 0x00007ffff799bc2d in QCoreApplicatio
#15 0x00007ffff799de07 in sendEve...
Chris Coulson (chrisccoulson) wrote : | #6 |
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 |
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 |
wondering if could be related to https:/ /bugs.launchpad .net/ubuntu- keyboard/ +bug/1306656