With Mir enabled, OSK remains hidden

Bug #1233550 reported by Richard Huddie on 2013-10-01
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mir
Invalid
Critical
Ricardo Mendoza
unity-mir
Undecided
Unassigned
ubuntu-keyboard (Ubuntu)
Critical
Günter Schwann
Saucy
Critical
Günter Schwann

Bug Description

20130929

PRE-REQUISITE:
Enable MIR on the device:
1. adb shell touch /home/phablet/.display-mir
2. adb reboot

TEST CASE:
1. Load messaging app and create a new message with the OSK in portrait mode
2. Tap in the message box to display the keyboard
3. Swipe down the OSK to hide it
4. Repeat steps 3 and 4 approx 4 or 5 times

EXPECTED RESULT:
Each time there is a tap in the message box the OSK should be displayed again. Each time the user swipes down, the OSK should be hidden.

ACTUAL RESULT:
For the first 3 times the OSK is displayed and hidden correctly. After the OSK has been hidden approximately 4 times it does not re-appear and the user cannot enter any text. Once this occurs it is not possible to use the OSK in any other app!!

This defect only occurs when MIR is enabled.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: ubuntu-keyboard 0.99.trunk.phablet2+13.10.20130926-0ubuntu1
Uname: Linux 3.4.0-3-mako armv7l
ApportVersion: 2.12.5-0ubuntu1
Architecture: armhf
Date: Tue Oct 1 08:13:36 2013
InstallationDate: Installed on 2013-09-29 (2 days ago)
InstallationMedia: Ubuntu Saucy Salamander (development branch) - armhf (20130929)
MarkForUpload: True
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
SourcePackage: ubuntu-keyboard
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Richard Huddie (rhuddie) wrote :
Bill Filler (bfiller) on 2013-10-01
Changed in ubuntu-keyboard (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Thomas Moenicke (thomas-moenicke)
summary: - With MIR enabled, OSK remains hidden
+ With Mir enabled, OSK remains hidden
no longer affects: mir (Ubuntu)
Richard Huddie (rhuddie) on 2013-10-02
tags: added: rls-s-incoming
kevin gunn (kgunn72) on 2013-10-04
Changed in mir:
status: New → Opinion
Changed in unity-mir:
status: New → Opinion
Bill Filler (bfiller) on 2013-10-07
Changed in ubuntu-keyboard (Ubuntu Saucy):
assignee: Thomas Moenicke (thomas-moenicke) → Gerry Boland (gerboland)
Bill Filler (bfiller) on 2013-10-15
Changed in ubuntu-keyboard (Ubuntu Saucy):
assignee: Gerry Boland (gerboland) → Günter Schwann (schwann)
Changed in mir:
assignee: nobody → Ricardo Mendoza (ricmm)
status: Opinion → Triaged
importance: Undecided → Critical
Bill Filler (bfiller) wrote :

My understanding of this issue from tmoenicke:
- setVisible(false) gets called on the osk window to hide it and setVisible(true) called to show it
- after multiple setVisible(false) calls then subsequent calls to setVisible(true) to not make the window appear anymore
- this only happens on MIR, worked fine with SF
- maliit-server is not crashing, it is still running when the problem occurs

Changed in ubuntu-keyboard (Ubuntu Saucy):
status: Triaged → In Progress
Günter Schwann (schwann) wrote :

Usually the keyboard (plugin) gets some
InputMethod::handleFocusChange(bool)
and at the end one
InputMethod::show()
When it should be shown.

But not in that case there is no call for either. Looks like there is no communication at all.

Showing/hiding the OSK by setting/removing the focus of the text field works fine it seems.

Bill Filler (bfiller) wrote :

latest debugging from gush:

I upgraded my MR - with that change, the OSK always remains hidden, after
swiping it away. So it's easier to reproduce the issue (at least on my maguro)
...

https://code.launchpad.net/~schwann/ubuntu-keyboard/keyboard-swipe-hide-show/+merge/191263

For the focus inside the app, or the app not having the focus. I don't think
that's the case. Otherwise the OSK would work again after switching to another
app.
So I rather think the issue is really on the maliit-server (the OSK) itself.

I just added a timer - printing a debug message every second.
When the display stays hidden, the output stops.
Which means the maliit-server process is frozen.

And with some debugging I can see that
"view->setVisible(false);" never returns. (view is a QQuickView object).

in "void closeOskWindow()" of file src/plugin/inputmethod_p.h
I used this debug messages:
    void closeOskWindow()
    {
        if (!view->isVisible())
            return;
        qWarning() << Q_FUNC_INFO << 1;
        host->notifyImInitiatedHiding();
        qWarning() << Q_FUNC_INFO << 2;
        qmlRootItem->setProperty("shown", false);
        qWarning() << Q_FUNC_INFO << 3;
        layout.updater.resetOnKeyboardClosed();
        qWarning() << Q_FUNC_INFO << 4;
        editor.clearPreedit();
        qWarning() << Q_FUNC_INFO << 5;
        view->setVisible(false);
        qWarning() << Q_FUNC_INFO << 6;
        applicationApiWrapper->reportOSKInvisible();
        qWarning() << Q_FUNC_INFO << 7;
    }

and got that output:
WARNING: void MaliitKeyboard::InputMethodPrivate::closeOskWindow() 1
WARNING: void MaliitKeyboard::InputMethodPrivate::closeOskWindow() 2
WARNING: void MaliitKeyboard::InputMethodPrivate::closeOskWindow() 3
WARNING: void MaliitKeyboard::InputMethodPrivate::closeOskWindow() 4
WARNING: void MaliitKeyboard::InputMethodPrivate::closeOskWindow() 5

Günter Schwann (schwann) wrote :

The hang is caused by this line: https://qt.gitorious.org/qt/qtdeclarative/source/d37547add0369d45182271754c0a35032d7de2d3:src/quick/items/qquickthreadedwindowmanager.cpp#L817

So the UI thread is waiting for the render thread to stop working - forever.

One easy "fix" is to disable the threaded rendering in Qt for maliit-server

Bill Filler (bfiller) on 2013-10-16
Changed in ubuntu-keyboard (Ubuntu Saucy):
status: In Progress → Fix Committed
Changed in unity-mir:
status: Opinion → Invalid
Changed in mir:
status: Triaged → Invalid
Bill Filler (bfiller) on 2014-01-24
Changed in ubuntu-keyboard (Ubuntu):
status: Fix Committed → Fix Released
Changed in ubuntu-keyboard (Ubuntu Saucy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers