806596 - [Browser] Browser resets the viewport to upper-left corner every time I un-focus the Username or Password field, on Gmail login page

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://gmail.com in B2G browser.
 2. Zoom in to upper-left corner, enough so that the username/password fields are now off-screen.  (Basically, enough so that the text is readable.)
 3. Pan over to username/password fields.
 4. Tap in "username" field.
     --> On-screen keyboard appears.
 5. Tap some blank space outside the "username" field, to un-focus it.

EXPECTED RESULTS: On-screen keyboard disappears, and the screen should otherwise look the same (exactly the way it was between steps 3 and 4).

ACTUAL RESULTS: On-screen keyboard disappears, ***and the viewport jumps over to the page's upper-left corner***, moving the username field out of view.

Comment 1

[Andrew Overholt [:overholt]]

Is the proper fix that we get the mobile site (what we get on Fennec) instead of the desktop site?

Daniel, can you try https://m.gmail.com to see if that helps?

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Andrew Overholt [:overholt] from comment #1)
> Is the proper fix that we get the mobile site (what we get on Fennec)
> instead of the desktop site?

That's a separate issue, IMHO.

> Daniel, can you try https://m.gmail.com to see if that helps?

That site does work (trivially), because it's much smaller, so I don't have to zoom in and pan around in order to get to text fields.

That doesn't make this bug fixed, though -- we still need to let people type text into textfields on the right side of large-ish pages, like the desktop-gmail login page.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase (try focusing, typing, & un-focusing the textfields on far-right side)

I was able to hit this a few times with this testcase, from zooming in, panning all the way to the upper-right, and tapping inside & outside the text-fields.  Most of the time, the viewport doesn't change, but it did snap back to the upper-left corner once or twice during a minute of testing.

Comment 4

[Andrew Overholt [:overholt]]

I've CC'd some people who may know what's going on here.

Thanks for the test case!

Comment 5

[Ben Francis [:benfrancis]]

Doug, the Gaia browser app has no control over how content is rendered inside an iframe, I think this will need a platform fix. That's why I moved it out of the Gaia component, is there a better place to file it to make sure it gets seen by the right eyes?

Comment 6

[Cervantes Yu [:cyu] [:cervantes]]

This is likely the single tap is taken as double tap handled by AsyncPanZoomController.

In mozilla::layers::GestureEventListener, after a tap happens, a delayed task is posted in hope of that it will be executed after 300 ms to timeout double tap and confirm single tap. If the main thread is busy, the delayed task might not get the chance to run and when the 2nd tap comes in, it is regarded as double tap even the interval is > 300ms. It could be fixed if we use the difference of event time to device whether this is a double tap.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Cervantes Yu from comment #6)
> In mozilla::layers::GestureEventListener, after a tap happens, a delayed
> task is posted in hope of that it will be executed after 300 ms to timeout
> double tap and confirm single tap. If the main thread is busy, the delayed
> task might not get the chance to run and when the 2nd tap comes in, it is
> regarded as double tap even the interval is > 300ms. It could be fixed if we
> use the difference of event time to device whether this is a double tap.

Sounds reasonable. Can you patch it?

Comment 8

[Cervantes Yu [:cyu] [:cervantes]]

I will work on a patch.

Comment 9

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Don't fire double tap if the delayed task fails to run in time to timeout the 1st tap

Comment 10

[Cervantes Yu [:cyu] [:cervantes]]

Test on try: https://tbpl.mozilla.org/?tree=Try&rev=c6b27e9ab79e

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 686051 [details] [diff] [review]
Don't fire double tap if the delayed task fails to run in time to timeout the 1st tap

Review of attachment 686051 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with that fixed

::: gfx/layers/ipc/GestureEventListener.cpp
@@ +137,5 @@
>  
>      NS_WARN_IF_FALSE(foundAlreadyExistingTouch, "Touch ended, but not in list");
>  
>      if (event.mTime - mTapStartTime <= MAX_TAP_TIME) {
> +      if (false && mState == GESTURE_WAITING_DOUBLE_TAP &&

I guess you don't want "false &&" here :-).

Comment 12

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Don't fire double tap if the delayed task fails to run in time to timeout the 1st tap

Carry over r+ with the test code removed.

Comment 13

[Cervantes Yu [:cyu] [:cervantes]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #11)
> I guess you don't want "false &&" here :-).

Ah! I forgot to remove it. Thanks :)

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/18038441ff7a

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/18038441ff7a

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/18038441ff7a

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d7a43a343314
https://hg.mozilla.org/releases/mozilla-beta/rev/9478c0b4fe8b