Open Bug 1501939 Opened 6 years ago Updated 2 years ago

Synthetic touch events should generate mouse{enter|leave|move|over|out} events -- including in RDM

Categories

(DevTools :: Responsive Design Mode, defect, P3)

Product:
DevTools
Component:
Responsive Design Mode
Version:
65 Branch
Type:
defect

Tracking

(Not tracked)

People

(Reporter: karlcow, Unassigned)

References

(Blocks 3 open bugs,
URL
)

Details

(Whiteboard: [rdm-reserve])

Attachments

(1 obsolete file)

To reproduce. 1. Enable touch events on Firefox responsive design mode 2. Go to https://w3c.github.io/uievents/tools/mouse-event-viewer.html 3. Tap ONCE green area. The sequence will be: 1. mousedown 2. mousemove 3. mouseup Do the same thing with chrome devtools with touch mode on The sequence will be 1. mouseover 2. mouseenter (*) 3. mousemove 4. mousedown 5. mouseup See Bug 1501921 for the initial context which led me to spend a lot of time of chasing an issue which was not here ;) Both Gecko, Edge and Blink are firing these events on a normal browsing environment with touch.
Summary: mouseenter/mouseleave are not fired with touch events on → mouseenter/mouseleave are not fired when setting touch events on RDM
I'll figure it out.
Assignee: nobody → bwerth
Priority: -- → P3
There's no spec on touch simulation (not that I'm aware of) for the browsers vendors to orient around. I understand that this could be considered a web-compatability issue (tools compat?), but the Firefox behavior seems intuitive and correct because there aren't mouseenter, mousemove and mouseleave events issued on touch devices. When simulating a touch device, why should the browser send those events? As a user, what are the use cases where it would be better for the browser to send these events than not?
Flags: needinfo?(kdubost)
Brad, Probably three things. 1. The simulation mode in Blink does it. 2. The website I was testing "Bug 1501921" in RDM+touch expected these, but I assumed wrongly that it would behave the same than Firefox on Android. 3. Firefox on Android does it.
Flags: needinfo?(kdubost)
Firefox on Android fires mouseenter events? In response to a tap? That is surprising to me. I'll see if I can get parity between our various Firefox platforms on this issue.
Jonathan, I'd like you to provide guidance here. Our Responsive Design Mode doesn't send mouse events when simulating touch events. According to Comment 3, Firefox for Android DOES send mouse events in addition to touch events. I'm building a test to codify this -- I can confirm the test fails on FF Desktop. Presuming that it passes on Android, meaning that we fire mouse events in addition to touch events on Android, should our RDM mode do the same? Or should Firefox Android change to only fire the touch events?
Flags: needinfo?(jwatt)
Using https://w3c.github.io/uievents/tools/mouse-event-viewer.html When tapping on A # Mobile -------- ## Chrome Canary 72.0.3602.0 on Android 9 1. mouseover 2. mouseenter 3. mousemove 4. mousedown 5. mouseup ## Firefox Nightly 65.0a1 2018-11-05 on Android 9 1. mouseover 2. mouseenter 3. mousemove 4. mousedown 5. mouseup # Desktop --------- ## Chrome Canary 72.0.3602.0 (64 bits) on macOS 1. mouseover (moving in) 2. mouseenter 3. mousemove 4. mousedown (click) 5. mouseup ## Chrome Canary 72.0.3602.0 (64 bits) on macOS + mobile emulator (devtools) 1. mouseover (tapping) 2. mouseenter 3. mousemove 4. mousedown 5. mouseup ## Firefox Nightly 65.0a1 (2018-11-05) (64-bit) on macOS 10.14 1. mouseover (moving in) 2. mouseenter 3. mousemove 4. mousedown (click) 5. mouseup ## Firefox Nightly 65.0a1 (2018-11-05) (64-bit) on macOS 10.14 + Touch events on (in RDM) 1. mousedown (tapping) 2. mousemove 3. mouseup
Yep, the test results[1] show that the test passes on Android (touch inputs also generate mouseenter, mouseleave, mousemove) and fails on Desktop (touch inputs do not generate thoese events). To be clear, the test is checking the behavior of actual touch events -- not something with RDM. This is a suprising result to me. Since it's possible that we have touch capable desktop users, I feel that we'd want the same events to be fired on FF Android as we do FF Desktop. It looks like to maximize web comptability, we would need to generate mouse events on both FF Desktop and in RDM. Jonathan, do you agree?
When Karl and I tried this on a touchscreen Windows device, we found we DO generate mouseenter/mouseexit on Firefox Desktop when touching but NOT when clicking in RDM using touch simulation. That is, the difference seemed to be with synthetic touch events, not actual ones.
Indeed, I am on a Windows touchscreen device now, and if I touch the green area from the test case in comment #0 I get "mouseenter". If I do the same in RDM mode with touch simulation enabled I do not.
(In reply to Brian Birtles (:birtles) from comment #11) > When Karl and I tried this on a touchscreen Windows device, we found we DO > generate mouseenter/mouseexit on Firefox Desktop when touching but NOT when > clicking in RDM using touch simulation. That is, the difference seemed to be > with synthetic touch events, not actual ones. Thank you for checking this. This sounds to me like we have a failure in our synthetic touch event code, which is also affecting RDM. That's what I'll fix.
Flags: needinfo?(jwatt)
Summary: mouseenter/mouseleave are not fired when setting touch events on RDM → Synthetic touch events should generate mouse{enter|leave|move|over|out} events -- including in RDM
For what it's worth, the Pointer Events specification has a section on compatibility mouse events, which mostly mirrors/follows what most browsers currently do for Touch Events as well https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events (while the reality used to be quite...fickle - as this has long been unspec'd behaviour ... see https://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-events for some older results; nowadays, most browsers seem to behave in a sane enough way, that is to say they follow what blink/webkit do for the most part)
Assignee: bwerth → nobody
Priority: P3 → P2
Whiteboard: [rdm-mvp]
Priority: P2 → P3
Whiteboard: [rdm-mvp] → [rdm-reserve]
Assignee: nobody → mtigley
Status: NEW → ASSIGNED

Update on mouse event sequence as of Firefox Nightly 79.0a1 (2020-06-06) :

RDM sequence

  1. mousemove
  2. mousedown
  3. mouseup

Firefox Android sequence

  1. mouseover
  2. mouseenter
  3. mousemove
  4. mousedown
  5. mouseup

This is a little tricky since the RDM touch simulator will receive both mouseover/mouseenter events from mouse input and then prevent-defaults them. By the time touchstart is dispatched, the pointing device is already over the boundaries of the target element so, based off the mouseover spec, the EventStateManager isn't going to dispatch anothermouseover and mouseenter. This is why we only see the three mouse events for the RDM sequence.

Based off https://www.w3.org/TR/touch-events/#mouse-events, we can assume that the touchstart event type will be dispatched before any subsequent mouse events. I can think of one approach to this problem:

  1. Don't dispatch mouseover and mouseenter events unless triggered from a touch event
  2. on touchstart set a flag somewhere indicating that a following mouseover can be dispatched
  3. In NotifyMouseOver, check that the following conditions are true:
    • target document is in RDM
    • touch simulation is enabled
    • the flag indicating that "touchstart" has been dispatched is true.
  4. If all the above conditions are met, then we can dispatch the mouseover event. Otherwise, ignore it.

(In reply to Micah Tigley [:mtigley] from comment #15)

Based off https://www.w3.org/TR/touch-events/#mouse-events, we can assume that the touchstart event type will be dispatched before any subsequent mouse events. I can think of one approach to this problem:

Thank you for finding a solution to this. This seems reasonable to me.

Assignee: mtigley → nobody
Status: ASSIGNED → NEW
No longer blocks: 1691322
Attachment #9022784 - Attachment is obsolete: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: