Closed Bug 1181703 Opened 6 years ago Closed 6 years ago
Panning/dragging operations in many Gaia apps will stop working, if you touch screen briefly w/ second finger
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)
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
Milan, does this seem graphics related?
QA Whiteboard: [foxfood-triage]
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
Milan, could you please take a look at this ?
Component: Gaia → Graphics: Layers
Product: Firefox OS → Core
6 years ago
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.
6 years ago
Assignee: nobody → bugmail.mozilla
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+
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.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) 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?
(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.