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

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: dholbert, Assigned: cyu)

Tracking

({b2g-testdriver, unagi})

unspecified
ARM
Gonk (Firefox OS)
b2g-testdriver, unagi

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

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.
Component: Gaia::Browser → General
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?
Flags: needinfo?(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.
Flags: needinfo?(dholbert)
Created attachment 677065 [details]
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.
I've CC'd some people who may know what's going on here.

Thanks for the test case!
blocking-basecamp: ? → +

Updated

6 years ago
Component: General → Gaia::Browser
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?
(Assignee)

Comment 6

6 years ago
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.
Component: Gaia::Browser → General
(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?
(Assignee)

Comment 8

6 years ago
I will work on a patch.
Assignee: ajones → cyu
(Assignee)

Comment 9

6 years ago
Created attachment 686051 [details] [diff] [review]
Don't fire double tap if the delayed task fails to run in time to timeout the 1st tap
Attachment #686051 - Flags: review?(roc)
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 :-).
Attachment #686051 - Flags: review?(roc) → review+
(Assignee)

Comment 12

6 years ago
Created attachment 686371 [details] [diff] [review]
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.
Attachment #686051 - Attachment is obsolete: true
Attachment #686371 - Flags: review+
(Assignee)

Comment 13

6 years ago
(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 :)
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/18038441ff7a
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-aurora/rev/d7a43a343314
https://hg.mozilla.org/releases/mozilla-beta/rev/9478c0b4fe8b
status-firefox18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
You need to log in before you can comment on or make changes to this bug.