keyboard layout flickers and hides on gmail

[Bill Filler]

build 83 rtm-proposed on krillin

1) Run the gmail webapp and compose a new message
2) The "To:" field has focus and the keyboard is showing (url layout with @ and .com key)
3) Tap in "CC:" field

Expected results:
keyboard stays visible with same url layout

Actual results:
keyboard switches to normal layout, then switches to url layout, then disappears

4) Tap in the "Bcc:" field and no keyboard is shown, Tap back in To: or CC: field and no keyboard is shown
5) Tap in Subject field and keyboard shown in normal layout
6) Now when switch to to, cc, or bc it works, but normal layout shown first then changes to url layout

Expected Result:
- if new layout is same as existing layout it shouldnt' first switch back to default layout
- keyboard should not be disappearing

[Bill Filler (bfiller)]

additionally, when the normal layout is shown, the word ribbon is shown and this disappears when it switches to url layout which makes the display flicker.

[Olivier Tilloy (osomon)]

I can reliably reproduce with a bare oxide WebView pointing to http://gmail.com (and with the user agent set to "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari").

[Victor Tuson Palau (vtuson)]

how can this not be critical?

[Joe Odukoya (jodukoya)]

This needs to be reclassified as Critical please.

[Olivier Tilloy (osomon)]

I instrumented oxide, and this is what I’m observing when switching the focus from the To: field to the Cc: field:

    OnTextInputStateChanged(): input type changes from EMAIL to NONE
    OnFocusedNodeChanged(): focus changes to non-editable node (probably the parent of both fields), OSK is requested to hide
    OnFocusedNodeChanged(): focus changes to an editable node (probably the Cc: field)
    OnTextInputStateChanged(): input type changes from NONE to EMAIL
    OnTextInputStateChanged(): OSK is requested to show

At this point the OSK has been requested to show, but it remains hidden, so it looks like it might be a bug in the OSK itself (if I tap again on the Cc: field, the OSK pops up, and I’m seeing no oxide state change).

Then if I give focus to the Bcc: field, the OSK reappears (contrary to the bug description), and here is the sequence of oxide events:

    OnTextInputStateChanged(): input type changes from EMAIL to NONE
    OnFocusedNodeChanged(): focus changes to another editable node (probably the Bcc: field)
    OnTextInputStateChanged(): input type changes from NONE to EMAIL
    OnTextInputStateChanged(): OSK is requested to show

The sequence of events in both cases looks correct.

Maybe we could try and make OnTextInputStateChanged() a bit more clever so as to not update the input method (and as a side effect the current layout) when the input type changes to NONE (as in this case either the OSK will be requested to hide, or the input type is going to change again).

[David Barth (dbarth)]

How can that be critical? The workaround is obvious: you re-click the field, and everything is back to normal. This is not a show stopper, it doesn't break the functionality of Gmail. This is UX polish.

.

[Olivier Tilloy (osomon)]

Downgrading to "High" per David’s comment. This is not a crash, and there is an easy, reliable and obvious workaround.

Note that we have a fix for the keyboard disappearing (not for the layout flickering yet, the issue might lie in ubuntu-keyboard).

[Olivier Tilloy (osomon)]

Regarding the flickering of the layouts: it seems that when requested to hide, the OSK queries the application for input hints (Qt::ImHints). At this point (when the first field has been unfocused, but the second one hasn’t received focus yet) the text input type has been reset, so oxide returns Qt::ImhNone, and as a consequence the layout is briefly reset to the default one.
Then the second field gets the focus, the OSK is requested to show again, and it queries the application for input hints, and oxide returns Qt::ImhEmailCharactersOnly.

It seems to me that we could avoid that by preventing the OSK from querying the application for input hints when it’s been requested to hide. What’s the point of changing the layout if the keyboard is going to hide anyway?

[Michael Sheldon (michael-sheldon)]

I've created a fix for the keyboard that prevents it querying for IME hints when hiding, however oxide still briefly reports incorrect IME hints when switching between fields without hiding, so I've opened an additional bug to track that: https://bugs.launchpad.net/oxide/+bug/1381083