Closed Bug 1806400 Opened 1 year ago Closed 1 month ago

Unreliable :active state, on android device with touchscreen and touchpad

Categories

(Core :: Panning and Zooming, defect, P2)

Firefox 108
All
Android
defect

Tracking

()

RESOLVED FIXED
126 Branch
Tracking Status
firefox126 --- fixed

People

(Reporter: ossman, Assigned: hiro)

References

Details

Attachments

(13 files)

546 bytes, text/html
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
777 bytes, text/html
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

Steps to reproduce:

  1. Create some input fields, e.g. <select>, <button>, <input type="image">
  2. Click said input fields

Actual results:

One of three things:

  1. No change in appearance at all (no visible :active)
  2. A brief visible change, often on release rather than press
  3. A permanent visible change (until something else on the page is clicked)

Expected results:

There should have been an immediate visible change for as long as I am pressing the input element. Once I release the element, it should immediately return to normal.

This was tested on a Samsung Galaxy Tab S7, both with the touch display and a trackpad.

The issue is only seen with Firefox, and only on Android.

<button>:s seem to work better than other input elements for some reason.

For behaviour 3, this mostly happens if you hold down the input element for too long. I'm guessing it is the right click timeout that triggers, just that Firefox doesn't do anything for a right click on these elements.

Thanks for the bug report. This sounds like a Gecko bug, so I'll forward to that team.

Component: General → DOM: Core & HTML
Product: Fenix → Core

I'm not sure that I understand what's going wrong, here. Are we talking about the :active pseudo class? Or is this something happening to input elements in general?

Is it that there is no visual feedback when interacting with input elements?

Flags: needinfo?(ossman)

Yes, that is correct. I'm not reliably seeing the expected visual feedback associated with the :active pseudo class.

Flags: needinfo?(ossman)

Pierre, I did some testing on Desktop (I don't have an Android device with me at the moment and Desktop should work the same as Android), can't reproduce it.

Is this specific to Android? Do you have a testing site/snippet that is reproducible for you?

Flags: needinfo?(ossman)

Yes, it is specific to only Android.

I'm afraid I don't have a simple test case, but you can see the issue here:

https://novnc.com/noVNC/vnc.html

The buttons in the toolbar are supposed to move a bit on :active to give the impression of being pressed.

Flags: needinfo?(ossman)

(In reply to Pierre Ossman from comment #6)

I'm afraid I don't have a simple test case, but you can see the issue here:

https://novnc.com/noVNC/vnc.html

The buttons in the toolbar are supposed to move a bit on :active to give the impression of being pressed.

I tested this page in Firefox 108 and Chrome 108 on Android 12. I'm not sure what the expected behavior is, but the button behavior is nicer is Firefox than Chrome:

  • When I tap and hold the gear button ⚙️ in Firefox, the button visually depresses and sometimes shows a grey highlight.
  • When I tap and hold the gear button ⚙️ in Chrome, the button's appearance doesn't change and Chrome opens a context menu with options to copy or share the button's image.

Hm... Perhaps this is device dependent. I'm afraid I don't have any other device than the Samsung tablet to test with here. I'm also testing with Firefox 108 and Chrome 108. I'm using Android 13, though.

I seem to be seeing the same bugs in Firefox on Linux with touch simulation enabled, though. Tested with Firefox 107 on Fedora 36 with X11.

Severity: -- → S2

Per our best understanding, :active is handled in APZ code.

Severity: S2 → --
Component: DOM: Core & HTML → Panning and Zooming

(In reply to Pierre Ossman from comment #1)

This was tested on a Samsung Galaxy Tab S7, both with the touch display and a trackpad.

I don't think operating an Android device with a trackpad is an input method we've ever tested.

I take it this is a standalone trackpad device? Could you say what model you use, and how you connect it to the Android device?


As for touch events, :active state handling for those is indeed managed by APZ.

(In reply to Pierre Ossman from comment #0)

Actual results:

One of three things:

  1. No change in appearance at all (no visible :active)
  2. A brief visible change, often on release rather than press
  3. A permanent visible change (until something else on the page is clicked)

I think I can explain #2: when we receive a touchstart event, we don't yet know if it's going to be part of a scroll gesture (touchstart -> touchmoves -> touchend), or a tap gesture (touchstart -> touchend). We don't want to enter the :active state in case of a scroll gesture, so it may not be until we get the touchend that we know it's a tap, at which point we enter the :active state, and schedule a short timer to leave it.

The click event is only dispatched when the timer elapses and the :active state is exited, which is why we keep the timer duration relatively short (to minimize responsiveness impact). We have bug 1816471 on file to decouple exiting the :active state from firing the click event, at which point we'll be able to keep the element in the :active state longer for better noticeability.

(also cc'ing Dan who has done recent work in this area of the code, for general awareness)

#1 and #3 sound like bugs.

Summary: Unreliable :active state → Unreliable :active state, on android device with touchscreen and touchpad

(In reply to Botond Ballo [:botond] from comment #10)

(In reply to Pierre Ossman from comment #1)

This was tested on a Samsung Galaxy Tab S7, both with the touch display and a trackpad.

I don't think operating an Android device with a trackpad is an input method we've ever tested.

I take it this is a standalone trackpad device? Could you say what model you use, and how you connect it to the Android device?

Toggling needinfo=reporter to be sure they see this^ question.

Flags: needinfo?(ossman)

Sorry for the delay. Things are hectic here...

(In reply to Botond Ballo [:botond] from comment #10)

I take it this is a standalone trackpad device? Could you say what model you use, and how you connect it to the Android device?

Yes and no. It's a detachable cover. It only works whilst connected to the device. I don't know if it communicates using the three connecting pins, or if those are just power and the rest is Bluetooth.

As mentioned in an earlier comment, this is Samsung Galaxy Tab S7, and it has the standard book cover with a keyboard and trackpad. You can see some images of it here:

https://www.samsung.com/se/mobile-accessories/galaxy-tab-s7-book-cover-keyboard-dt870-ef-dt870bbegse/

Flags: needinfo?(ossman)

Thanks. While we don't have the mentioned device specifically available to test, we've tried attaching an external touchpad to a phone using a USB cable, and some preliminary experimentation suggests that the OS sends touch events for touchpad input. This would be consistent with you observing the same behaviour for touchpad and touchscreen input.

I'm going to mark this as a P2 to at least track the following:

  • Further experimentation with touchpad input on Android to identify any significant gaps in support for this input method (which we can then file and track separately).
  • Seeing if we can reproduce issues #1 and #3 from comment 0 (with either touchscreen or touchpad).

(Also adding bug 1816471 to "See Also" as I've identified that in comment 10 as a potential mitigation for issue #2.)

Severity: -- → S3
Priority: -- → P2
See Also: → 1816471
Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Duplicate of bug: 1724759
Resolution: --- → DUPLICATE

Thanks for pointing to bug 1724759; I believe that could be the explanation for issue #3 in comment 0 (especially since in comment 1 Pierre mentioned that "behaviour 3 ... mostly happens if you hold down the input element for too long").

This is not quite a duplicate, though, as this bug also tracks investigation of additional issues, as discussed in comment 13. I'm reopening this and making bug 1724759 a dependency.

Status: RESOLVED → REOPENED
Depends on: 1724759
No longer duplicate of bug: 1724759
Ever confirmed: true
Resolution: DUPLICATE → ---

It involves an active touchstart event listener.

There are three different problems;

  1. In the test case in comment 16 APZStateChange notifications, eStartTouch and eEndTouch arrive after eTouchEnd event in APZEventState
  2. With regard to 1) if eTouchEnd arrives before eEndTouch, the mEndTouchIsClick value isn't reliable
  3. Though we don't clear the active state in EventStateManager if mouse up event is triggered by touch, we do active on mousedown event by touch

(In reply to Hiroyuki Ikezoe (:hiro) from comment #17)

  1. In the test case in comment 16 APZStateChange notifications, eStartTouch and eEndTouch arrive after eTouchEnd event in APZEventState
  2. With regard to 1) if eTouchEnd arrives before eEndTouch, the mEndTouchIsClick value isn't reliable

That looks like what I described in bug 1816467 comment 1.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #17)

  1. Though we don't clear the active state in EventStateManager if mouse up event is triggered by touch, we do active on mousedown event by touch

That sounds like it might be a regression from bug 1816473 which introduced the MOZ_SOURCE_TOUCH check. We talked about other places where MOZ_SOURCE_TOUCH might be set in this review thread but may have overlooked something.

Though I've fixed the three problems locally, but I found there's one more problem that is that ActiveElementManager::ProcessSingleTap gets sometimes called in between APZStateChange::eStartTouch and eTouchEnd event, thus DelayedClearElementActivation doesn't properly clear the active state.

(In reply to Botond Ballo [:botond] from comment #18)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #17)

  1. In the test case in comment 16 APZStateChange notifications, eStartTouch and eEndTouch arrive after eTouchEnd event in APZEventState
  2. With regard to 1) if eTouchEnd arrives before eEndTouch, the mEndTouchIsClick value isn't reliable

That looks like what I described in bug 1816467 comment 1.

Yeah, looks like bug 1816467 can be merged into this bug. Once after this bug was fixed, I will close it as a dup.

I pushed all patches to fix this bug to phab (it hasn't yet been published here for some reasons though), but it's not ready to be reviewed. Because it makes helper_touch_synthesized_mouseevents.html=scrollable=true fail intermittently. Anyways, I finally figured out how the test fails.

The test waits for mousedown, mousemove mouseup and click events and checks the target element's :active state. But if the target element is inside an APZ scrollable container, APZStateChange::eStartTouch notification is delayed as 1) in comment 17. In such cases, with fixing 3 in comment 17 the target element's :active state hasn't yet been activated. In other words on the current m-c, the test unexpected has been passing due to 3 in comment 17.

So I am wondering what the proper way is to make the test work as expected with avoiding breaking the test purpose? Given that the test is for not-delaying mouse events (bug 1816473), just waiting for :active state change with SimpleTest.promiseWaitForCondition just like I did in helper_bug1724759.html is fine?

Dan, any opinions?

Flags: needinfo?(drobertson)

APZStateChange::eEndTouch notification arrives after eTouchEnd event in some
cases, thus in such cases setting mEndTouchIsClick only on
APZStateChange::eEndTouch notification causes a situation that the previous
mEndTouchIsClick is used on the next eTouchEnd event.

If it's not pannable, the activation should have been done in
ActiveElementManager::TriggerElementActivation().

So I am wondering what the proper way is to make the test work as expected with avoiding breaking the test purpose? Given that the test is for not-delaying mouse events (bug 1816473), just waiting for :active state change with SimpleTest.promiseWaitForCondition just like I did in helper_bug1724759.html is fine?

Dan, any opinions?

Yeah, I think this would be a good condition to add to the promises list.

Flags: needinfo?(drobertson)
Blocks: 1816467
Attachment #9375320 - Attachment description: Bug 1806400 - Ignore mousedown event by touch to activate element in EventStateManager. → WIP: Bug 1806400 - Ignore mousedown event by touch to activate element in EventStateManager.
Attachment #9375322 - Attachment description: Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. → WIP: Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`.
Attachment #9375321 - Attachment description: Bug 1806400 - Reset `mEndTouchIsClick` on `eTouchStart`. → WIP: Bug 1806400 - Reset `mEndTouchIsClick` after both of `APZStateChange::eEndTouch` and `eTouchEnd` event have been handled.
Attachment #9375323 - Attachment description: Bug 1806400 - Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable. → WIP: Bug 1806400 - Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable.
Attachment #9375324 - Attachment description: Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. → WIP: Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created.
Attachment #9375325 - Attachment description: Bug 1806400 - A mochitest for :active state change with touchstart event listener. → WIP: Bug 1806400 - A mochitest for :active state change with touchstart event listener.
See Also: → 1875916

There's another race condition which hadn't been addressed by the posted patches. The race is;

  1. APZStateChange::eStartTouch
  2. APZStateChange::eEndTouch
  3. touch-start event

Then at 2) mCanBePanSet is cleared, thus at 3) we fail to activate.

There's a race condition where APZStateChange notifications and touch-start
event happen in the following order;

  1. APZStateChange::eStartTouch
  2. APZStateChange::eEndTouch
  3. touch-start event

Thus in 2) mCanBePanSet was reset before using the flag at 3).

Depends on D199028

Assignee: nobody → hikezoe.birchill
Attachment #9375712 - Attachment description: WIP: Bug 1806400 - Wait for :active state change explicitely in helper_touch_synthesized_mouseevents.html. → Bug 1806400 - Wait for :active state change explicitely in helper_touch_synthesized_mouseevents.html. r?dlrobertson
Attachment #9375320 - Attachment description: WIP: Bug 1806400 - Ignore mousedown event by touch to activate element in EventStateManager. → Bug 1806400 - Ignore mousedown event by touch to activate element in EventStateManager. r?botond
Attachment #9375322 - Attachment description: WIP: Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. → Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. r?botond
Attachment #9375321 - Attachment description: WIP: Bug 1806400 - Reset `mEndTouchIsClick` after both of `APZStateChange::eEndTouch` and `eTouchEnd` event have been handled. → Bug 1806400 - Reset `mEndTouchIsClick` after both of `APZStateChange::eEndTouch` and `eTouchEnd` event have been handled. r?botond
Attachment #9375323 - Attachment description: WIP: Bug 1806400 - Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable. → Bug 1806400 - Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable. r?botond
Attachment #9375324 - Attachment description: WIP: Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. → Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?botond
Attachment #9375864 - Attachment description: WIP: Bug 1806400 - Reset `mCanBePanSet` to false after both of `APZStateChange::eStartTouch` and `eTouchStart` event have been handled. → Bug 1806400 - Reset `mCanBePanSet` to false after both of `APZStateChange::eStartTouch` and `eTouchStart` event have been handled. r?botond
Attachment #9375325 - Attachment description: WIP: Bug 1806400 - A mochitest for :active state change with touchstart event listener. → Bug 1806400 - A mochitest for :active state change with touchstart event listener. r?botond

Dan, I guess D199028 is unnecessary after bug 1858610 is fixed. I will try to confirm it once the patch for the bug was updated.

The following patches are waiting for review from an inactive reviewer:

ID Title Author Reviewer Status
D199024 Bug 1806400 - Ignore mousedown event by touch to activate element in EventStateManager. r?botond hiro botond: Back Feb 21, 2024
D199025 Bug 1806400 - Reset mEndTouchIsClick after both of APZStateChange::eEndTouch and eTouchEnd event have been handled. r?botond hiro botond: Back Feb 21, 2024
D199026 Bug 1806400 - Change active state either on APZStateChange::eEndTouch or eTouchEnd. r?botond hiro botond: Back Feb 21, 2024
D199027 Bug 1806400 - Activate both on touchend event or on touchend notification only if the touch event is pannable. r?botond hiro botond: Back Feb 21, 2024
D199028 Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?botond hiro botond: Back Feb 21, 2024
D199029 Bug 1806400 - A mochitest for :active state change with touchstart event listener. r?botond hiro botond: Back Feb 21, 2024
D199282 Bug 1806400 - Reset mCanBePanSet to false after both of APZStateChange::eStartTouch and eTouchStart event have been handled. r?botond hiro botond: Back Feb 21, 2024

:hiro, could you please find another reviewer?

For more information, please visit BugBot documentation.

Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(hikezoe.birchill)
Attachment #9375325 - Attachment description: Bug 1806400 - A mochitest for :active state change with touchstart event listener. r?botond → Bug 1806400 - A mochitest for :active state change with touchstart event listener. r?dlrobertson
Attachment #9375322 - Attachment description: Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. r?botond → Bug 1806400 - Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. r?dlrobertson
Attachment #9375324 - Attachment description: Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?botond → Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?dlrobertson
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7d1d8ba28a7f
Wait for :active state change explicitely in helper_touch_synthesized_mouseevents.html. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/43175acb60fc
Ignore mousedown event by touch to activate element in EventStateManager. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/01f63c388f1e
Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/7dfd76acbfe8
Reset `mEndTouchIsClick` after both of `APZStateChange::eEndTouch` and `eTouchEnd` event have been handled. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/0ad571f73504
Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/f63cc5d45f1c
Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/dac639d70f03
Reset `mCanBePanSet` to false after both of `APZStateChange::eStartTouch` and `eTouchStart` event have been handled. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/714d9f890934
A mochitest for :active state change with touchstart event listener. r=dlrobertson

Backed out for causing OS X mochitests plain failures in test_group_mouseevents.html.

Flags: needinfo?(hikezoe.birchill)

So the failure on Mac is caused by the difference that double-tap-to-zoom is enabled by apz.mac.enable_double_tap_zoom_touchpad_gesture on Mac. Thus in AsyncPanZoomController::OnSingleTapUp we don't immediately generate a single-tap event. I haven't tackled this race condition in the patch series I've posted.

The reason why the failure wasn't caught on Android is the test in question is disabled on Android.

Anyways, my conclusion here at this moment is skipping the test on Mac should be fine since we don't support touch screen on Mac, but the race will definitely happen on Android, we need to solve it.

Flags: needinfo?(hikezoe.birchill)

On environments double-tap-to-zoom is enabled, it's possible that a single-tap
event happens after ActiveElementManager have already processed both of
touchend event and APZStateChange::eEndTouch notification from APZ. In such
cases we need to wait for the delayed single-tap event.

The mochitest in this change is a subset of
helper_touch_synthesized_mouseevents.html?scrollable=true.

I uploaded D202384 to address the race we can observe on Mac. That said, I understand D202384 is not a good approach to fix the race since it relies on an assumption that whenever we got a touchend event in an APZC, we will send a single-tap event. That's not true, a case I know of is where we fire a long-tap event. If no single-tap event is observed we never call ActiveElementManager::ResetTouchBlockState(). That will break the next touch event block.

As of now I have no alternative idea, so I just uploaded it as a reference.

While I have no idea to fix the race in comment 37 that the target element activation doesn't happen while double tapping on the element, I wondered whether the activation should happen on double tapping or not.

Attaching file is an example to see the result. On Firefox no activation happens. On Chrome it happens.

(Note that in either case no click event observes)

So now I am leaning to send a new single tap message here in AsyncPanZoomController::OnSingleTapUp which isn't used to fire a click event even if the content allows double-tap-zooming, and use the message to tell whether we need to activate the element or not.

Does this sound a promising approach, Botond, Dan?

Flags: needinfo?(drobertson)
Flags: needinfo?(botond)

My initial reaction is that it seems like a promising approach. I do wonder if there are cases where sending a single tap could change the seen behavior. I think the following might be an interesting case to keep in mind:

  1. A page contains an image that is a link or has an onclick handler that changes the page somehow or causes a navigation.
  2. The user double-taps the image

The user may be expecting us to zoom in on the image, but if we send a new single tap message in this case, we'd need to ensure the handle tap message does not synthesize click events.

Flags: needinfo?(drobertson)

Thanks Dan. That's exactly I had in my mind.

After reading relevant code, now I think just invoking this SetSingleTapOccurred might be sufficient instead of sending the new tap message.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #42)

Thanks Dan. That's exactly I had in my mind.

After reading relevant code, now I think just invoking this SetSingleTapOccurred might be sufficient instead of sending the new tap message.

I am almost 100% sure that this is the right direction. I will upload a patch soon.

Flags: needinfo?(botond)
Attachment #9381925 - Attachment description: WIP: Bug 1806400 - Make element activation work properly even if a single-tap event happened lastly. r?dlrobertson!,botond → Bug 1806400 - Activate the target element on the first tap during double tapping. r?dlrobertson!,botond!
Attachment #9375324 - Attachment description: Bug 1806400 - Ensure to invokve DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?dlrobertson → Bug 1806400 - Ensure to invoke DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r?dlrobertson

This fixes a regression in D199027. The regression is that element activation
happened even on double-tapping.

The regression scenario happens on environments where double-tap-zoom is allowed
and where the target APZC is pannable. When the APZC received the first
touch-end event the APZC doesn't send a single tap event immediately. In the
meantime the ActiveElementManager tries to generate a SetActiveTask after both
of touch-start event and start touch notification received, but sometimes the
first touch-end event arrives to the ActiveElementManager before the touch-start
event (this case is handled in D199282), thus the CancelTask in
HandleTouchEndEvent() got called first, then a SetActiveTask was generated.

Attachment #9381925 - Attachment description: Bug 1806400 - Activate the target element on the first tap during double tapping. r?dlrobertson!,botond! → Bug 1806400 - Activate the target element in ProcessSingleTap() on the first tap if double-tap didn't happen. r?dlrobertson!,botond!

NOTE: The main part of this change is the call site of
NotifyAPZStateChange(eStartTouch) in AsyncPanZoomController::OnTouchStart.
Other parts are just renaming.

Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/524abee5b6fe
Wait for :active state change explicitely in helper_touch_synthesized_mouseevents.html. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/11b211f2ac66
Ignore mousedown event by touch to activate element in EventStateManager. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/fc2f50e49e2a
Change active state either on `APZStateChange::eEndTouch` or `eTouchEnd`. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/da70f9758ad5
Reset `mEndTouchIsClick` after both of `APZStateChange::eEndTouch` and `eTouchEnd` event have been handled. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/140e6894d9a8
Activate both on `touchend` event or on `touchend` notification only if the touch event is pannable. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/4acd237193a7
Ensure to invoke DelayedClearElementActivation::MarkSingleTapProcessed even if DelayedClearElementActivation hasn't yet been created. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/bfabdf579353
Reset `mCanBePanSet` to false after both of `APZStateChange::eStartTouch` and `eTouchStart` event have been handled. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/e46abfacd114
A mochitest for :active state change with touchstart event listener. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/e86ee7e76c17
Move the CancelTask call in HandleTouchEndEvent() into MaybeChangeActiveState(). r=botond
https://hg.mozilla.org/integration/autoland/rev/637b67cd5a71
Activate the target element in ProcessSingleTap() on the first tap if double-tap didn't happen. r=dlrobertson,botond
https://hg.mozilla.org/integration/autoland/rev/fdef19004c15
Defer element activation on touch-start on environments where double-tap-to-zoom is allowed. r=botond
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: