1176926 - [InputMgmt] Tapping between bottom text fields jumps/shifts the screen unnecessarily

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

Description

[Oliver Nelson [:oliverthor]]

Attachment: logcat_20150623_1248.txt

Description:
When the user is toggling between text fields near the bottom of an app, they may observe that the screen has the capacity to 'jump' when transitioning. This may be a result of the size of the screen and the location of these text fields in relation to that. Expected behavior is only the cursor to move if the other UI is visible on screen. However, the UI shifts notably (scan up then down) drawing attention to the jump.
This has been observed in 2 areas at least:
* Manually signing in Email Accounts (Outlook/Hotmail |or| Gmail)
* Creating a new Contact (Additional Comment Fields)

Repro Steps:
1) Update a Aries to 20150622125855
2) Open the Contacts app
3) Create a new contact
4) Scroll to bottom of page
5) Add a new Comment property (tap + sign, should have 2 large text fields)
6) Scroll to bottom
7) Tap lower Comment text field
8) Tap upper Comment text field
9) Repeat 6-8 to observe issue

Actual:
UI frame of view shifts harshlywhen toggling between multiple text fields located on the bottom of a UI screen

Expected:
UI frame of view remains static (to the best of it's ability) when toggling between multiple text fields


Environmental Variables:
------------------------------

Device: Aries 3.0
Build ID: 20150622125855
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: cddf3b36b5e2
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Device: Flame 3.0
BuildID: 20150622160206
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: be81b8d6fae9
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
*************************************

Issue DOES NOT REPRODUCE on 2.2 for flame devices
Results: UI frame of view remains static (to the best of it's ability) when toggling between multiple text fields

Device: Flame 2.2
BuildID: 20150623002504
Gaia: 1f8981d7872e3c0053571c26fb3edaf401844d75
Gecko: 9a0d8f7b1200
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
--------------------------------------------------


Repro frequency: 5/5
See attached: 
video- https://youtu.be/6tIW2v4xkT4
logcat

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

Nominating this 3.0? since this is a regression and will lead to end user frustration.

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

Mozilla Inbound

Last working
Environmental Variables:
Device: Flame 3.0
Build ID: 20150614213841
Gaia: 1bf2da102560481748ff3f6202fbed5c4daa5832
Gecko: a493653ebbed
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First Broken
Environmental Variables:
Device: Flame 3.0
Build ID: 20150615000842
Gaia: 1bf2da102560481748ff3f6202fbed5c4daa5832
Gecko: 85383f7a9d53
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce
Gaia: 1bf2da102560481748ff3f6202fbed5c4daa5832
Gecko: 85383f7a9d53

First Broken Gaia Last Working Gecko: Issue DOES NOT reproduce
Gaia: 1bf2da102560481748ff3f6202fbed5c4daa5832
Gecko: a493653ebbed

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a493653ebbed&tochange=85383f7a9d53

This seems to have been caused by the landing bug 1162360.

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

Tim, here is another issue that could have been caused by the landing for bug 1162360. Should we back out that landing at this point?

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to KTucker [:KTucker] from comment #3)
> Tim, here is another issue that could have been caused by the landing for
> bug 1162360. Should we back out that landing at this point?

You are right. This is more disruptive to the users than I thought. I am going to fix this by introducing a timeout in System Input Mgmt.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Github: https://github.com/mozilla-b2g/gaia/pull/30745

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8627491 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/30745

mnjul, I know you are having fun right now but you are the most qualified person to do the review. This test re-introduces a wait-before-resize so that the viewport of the foreground window will not be resized when the focus moves (and back) in a short timing.

The entirely story is documented in the comment with all the related bug referenced.

As a proof of the patch surpasses bug 1171950 comment 2, the following pull requests proves we can backout bug 1171387 and bug 1174062 and still keep the tests passes.

https://github.com/mozilla-b2g/gaia/pull/30746
https://github.com/mozilla-b2g/gaia/pull/30747

Rudy, not sure if could review this.

Comment 8

[John Lu [:mnjul][Please NI or I'll miss]]

Please give me some time, I'd like to double-check into all the referenced bugs :)

Comment 9

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8627491 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/30745

So it all boils down to the inability to correctly/reliably order blur/focus event sequences sent to gaia when such events happen across inproc/oop apps boundary, which is really a long-standing issue. It scares me that such issue takes so many patches and repercussions felt far and wide --

Anyway, the patch looks good to me, as long as the Promise pattern built at bug 1162383 suits the need. There're currently two patterns mixed together (events / handlers and promise chains) to achieve state machine / lockstepping, at IWM, which might be a bit disturbing.

Other than that, please check my GH comment for the timeout value (which is trivial).

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/5a1f388bd322982c9901e8d24abfc81338841dd2

Comment 11

[Pi Wei Cheng [:piwei] (inactive)]

This issue is verified fixed on both Aries and Flame. However, the bug that was duped to this (bug 1176771) is not completely fixed. 1176771 appears to be fixed on Aries but not on Flame. I'll be re-opening that bug and comment with new information.

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150715010202
Gaia: c6ef08964711f461a8e6326eae911789d1ec220c
Gecko: c95ebeebbc5d
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Aries (RC4 and OTA'ed to dogfood-latest)
BuildID: 20150715180430
Gaia: b9968cdc4a1dee49848fed6159a59c378cea062d
Gecko: 49683d4e9ebd
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0