Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Panning/dragging operations in many Gaia apps will stop working, if you touch screen briefly w/ second finger

RESOLVED FIXED in Firefox 45

Status

()

Core
Panning and Zooming
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: dholbert, Assigned: kats)

Tracking

({foxfood})

unspecified
mozilla45
ARM
Gonk (Firefox OS)
foxfood
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
STR: (using the homescreen app as an example; this affects many apps though)

1. Touch the homescreen with 1 finger. Pan up and down. Do not remove this finger.

2. Briefly tap a blank space on the screen with a second finger.

3. Try to continue panning with your (still-touching) first finger.

ACTUAL RESULTS: All touches from your first finger are dropped after you've tapped the screen with your second finger.  So, the panning just stops working, until you completely stop touching the screen.

EXPECTED RESULTS: Panning w/ first finger should keep working, after I've removed second finger.


I get similar ACTUAL RESULTS when briefly tapping a second finger, during all of the following scenarios:
 - panning around a zoomed-in photo in the Gallery app
 - panning around a zoomed-in web page (planet.m.o)\
 - scrolling through the Settings app's toplevel menu
 - dragging the slider on the lockscreen


This isn't universally broken, though -- I get EXPECTED RESULTS in a few other selected places:
 - dragging the clock-spinners when choosing a time for the alarm clock
 - dragging the clock-spinner when choosing a time in Clock's "Timer" view.
 - scrolling the "edit alarm" menu up & down, in Clock app. (I occasionally hit this bug there, but only a small fraction of the time instead of all the time.)
 - mapping applications like Google Maps (though I hit bug 1181648 instead)
(Reporter)

Comment 1

2 years ago
Build info from check_versions.py:

Build ID               20150707033152
Gaia Revision          e6506d68e01489b57616f8b74e8773f938ce62b3
Gaia Date              2015-07-06 18:14:41
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e271ef4c49ae
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150619.015544
Firmware Date          Fri Jun 19 01:55:53 UTC 2015
Bootloader             s1
(Reporter)

Updated

2 years ago
Keywords: foxfood
(Reporter)

Updated

2 years ago
Component: General → Gaia
Milan, does this seem graphics related?
QA Whiteboard: [foxfood-triage]
Flags: needinfo?(milan)
After you have two fingers down, we want to lift one finger and do panning.  I imagine this is a duplicate, or at least related to bug 962243.  Botond, if you agree, we can just dupe this to bug 962243.
Flags: needinfo?(milan) → needinfo?(botond)
It looks like this would be a small extension to bug 962243.

The plan there is to go back to panning if we receive a touch-end while the gesture detector is in the GESTURE_PINCH state. To address this, we'd just need to do the same thing if we're in the GESTURE_MULTI_TOUCH_DOWN state (that's the state we're in if you've put a second finger down but haven't started pinching yet).
Depends on: 962243
Flags: needinfo?(botond)
Milan, could you please take a look at this ?
Component: Gaia → Graphics: Layers
Product: Firefox OS → Core
Component: Graphics: Layers → Panning and Zooming
We should fix this sooner rather than later, because Fennec currently does this correctly and when it switches to C++ APZ it will regress.
Blocks: 1206872
Assignee: nobody → bugmail.mozilla
Created attachment 8689672 [details] [diff] [review]
Patch

Beyond the patch for bug 962243 the only problem here was that when we got the touch-end for the "tap" we were going back to state NOTHING even though we a finger down still. So I exposed the touch counter from the touch block state and used that to detect this scenario.
Attachment #8689672 - Flags: review?(botond)
Comment on attachment 8689672 [details] [diff] [review]
Patch

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

This could also be gtested, but I'll leave it up to you to decide if it's worth it.
Attachment #8689672 - Flags: review?(botond) → review+
Created attachment 8689839 [details] [diff] [review]
Part 2 - Gtest
Attachment #8689839 - Flags: review?(botond)
Comment on attachment 8689839 [details] [diff] [review]
Part 2 - Gtest

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

Thanks!

::: gfx/layers/apz/test/gtest/TestAsyncPanZoomController.cpp
@@ +1060,5 @@
> +  mti = MultiTouchInput(MultiTouchInput::MULTITOUCH_END, 0, TimeStamp(), 0);
> +  mti.mTouches.AppendElement(CreateSingleTouchData(secondFingerId, touchX + 10, touchY));
> +  apzc->ReceiveInputEvent(mti, nullptr);
> +
> +  // Bust through the threshold again

Have we considered whether having to break through the threshold again after the tap of the second finger is desirable?
Attachment #8689839 - Flags: review?(botond) → review+
I don't have any arguments for either one, and this was how it worked out. In particular the second finger going down creates a new input block which will be redirected to the root content document; lifting the second finger could mean that you are now scrolling a different APZC than when you started. That's why the threshold re-appears. Getting rid of it will be tricky so I'm inclined to leave it unless there are strong arguments for removing it.

Comment 12

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/012257e6f0bf
https://hg.mozilla.org/integration/mozilla-inbound/rev/9dfe9b8e6d78
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> In particular the second finger going down creates a new input block which
> will be redirected to the root content document; lifting the second finger
> could mean that you are now scrolling a different APZC than when you
> started.

Ah, good point; I didn't fully appreciate this before. I guess this means that if you're on a page where the main scrollable frame is a subframe, tapping with a second finger will still kill the pan?
https://hg.mozilla.org/mozilla-central/rev/012257e6f0bf
https://hg.mozilla.org/mozilla-central/rev/9dfe9b8e6d78
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
(In reply to Botond Ballo [:botond] from comment #13)
> Ah, good point; I didn't fully appreciate this before. I guess this means
> that if you're on a page where the main scrollable frame is a subframe,
> tapping with a second finger will still kill the pan?

Yeah, it does.
You need to log in before you can comment on or make changes to this bug.