GMail webapp keyboard hide and seek

Bug #1566373 reported by Allan LeSage
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Band-aids for Ubuntu Phone
New
Undecided
Unassigned
Canonical System Image
Confirmed
Critical
David Barth
webapps-sprint
Triaged
High
Unassigned
webbrowser-app (Ubuntu)
Confirmed
High
Unassigned

Bug Description

This is possibly a keyboard problem instead, please feel free to reassign as necessary. Testing with Frieza r75.

TEST CASE
GMail account connected, GMail app open, landscape mode
1. Compose e-mail, compose screen appears
2. Tap in address header
EXPECTED
Keyboard appears
ACTUAL
Keyboard appears, keyboard immediately hides

Possibly this is a layout issue; also the delay in opening the keyboard (blank white space left open during delay) may explain? Here's a link to a video (note upside-down :/ ): http://people.canonical.com/~alesage/video20160404_164751052.mp4 .

Tags: bq-feedback
Changed in webbrowser-app (Ubuntu):
assignee: nobody → Alexandre Abreu (abreu-alexandre)
Changed in canonical-devices-system-image:
status: New → Confirmed
importance: Undecided → Critical
assignee: nobody → David Barth (dbarth)
milestone: none → 11
Changed in webapps-sprint:
milestone: none → sprint-21
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
assignee: Alexandre Abreu (abreu-alexandre) → Olivier Tilloy (osomon)
importance: Undecided → High
David Barth (dbarth)
Changed in webapps-sprint:
assignee: nobody → Alexandre Abreu (abreu-alexandre)
status: New → Triaged
milestone: sprint-21 → sprint-22
Revision history for this message
Olivier Tilloy (osomon) wrote :

Something (I don’t know what yet) appears to be briefly stealing focus from the webview when the "Compose" button is tapped.

I monitor changes to Window.activeFocusItem and I’m seeing it change twice, although the value of the activeFocusItem is always the webview (if activeFocusItemChanged is emitted, there must be another item that is getting the active focus in between though).

I cannot reproduce the issue with a plain oxide WebView inside a MainView, so there is something that is webbrowser-app/webapp-container specific.

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

I instrumented oxide to be notified on focusInEvent() and focusOutEvent() on the webview, and when composing a new message neither is emitted (as expected). Still the QML window reports that its activeFocusItem has changed.

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

The QML window reporting that its activeFocusItem has changed without it actually changing is most likely due to the workaround for bug #1323743 in oxide. This should be harmless.

tags: added: bq-feedback
Revision history for this message
Olivier Tilloy (osomon) wrote :

Note that the problem is not observed when changing the UA string for gmail to that of chrome on android, e.g.:

    Mozilla/5.0 (Linux; Android 4.4.2; Nexus 10 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.108 Safari/537.36

This doesn’t solve the issue though, because the UA string we expose is based on screen size only, so we don’t differentiate between a 10" tablet and a desktop computer.

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

When pressing the compose button, I’m seeing RenderViewImpl::focusedNodeChanged() being called three times:
 1) [null → div]
 2) [div → textarea(to:)]
 3) [textarea(to:) → null]

If I then tap the "Subject:" field, RenderViewImpl::focusedNodeChanged() is called only once: [null → input(subject:)].

The text area initially gets focus, as expected, but looses it right away, for a reason that still escapes me.
It looks like it’s not touch-friendly.

David Barth (dbarth)
Changed in webapps-sprint:
assignee: Alexandre Abreu (abreu-alexandre) → Olivier Tilloy (osomon)
Changed in canonical-devices-system-image:
milestone: 11 → 12
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

With the GMail desktop UI, resizing the window causes it to remove focus from the input elements in the compose UI - you can reproduce this with the GMail webapp on a desktop.

I suspect this is relevant, given that the webapp is resized on the tablet when the OSK is displayed

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

And the same behaviour happens with GMail in Chrome/Desktop

David Barth (dbarth)
Changed in webapps-sprint:
milestone: sprint-22 → sprint-23
importance: Undecided → High
David Barth (dbarth)
Changed in webapps-sprint:
milestone: sprint-23 → sprint-24
Changed in canonical-devices-system-image:
milestone: 12 → 13
David Barth (dbarth)
Changed in webapps-sprint:
milestone: sprint-24 → sprint-25
Revision history for this message
Victor gonzalez (victor-gonzalez-0) wrote :

Still happening on Frieza's rc-proposed, always reproducible in portrait mode:

current build number: 171
device name: frieza
channel: ubuntu-touch/rc-proposed/bq-aquaris-pd.en
last update: 2016-08-18 09:03:34
version version: 171
version ubuntu: 20160818
version device: 20160809.0
version custom: 20160805--42-20-vivid

Changed in canonical-devices-system-image:
milestone: 13 → backlog
Olivier Tilloy (osomon)
Changed in webapps-sprint:
assignee: Olivier Tilloy (osomon) → nobody
Changed in webbrowser-app (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
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.