onMouseEnter/onMouseLeave events no longer fire for TouchableHighlight component

Environment

1. npx react-native --version:
   4.10.0
2. npx react-native run-windows --info:
   System:
   OS: Windows 10 10.0.18363
   CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
   Memory: 4.34 GB / 15.92 GB
   Binaries:
   Node: 12.18.3 - C:\Program Files\nodejs\node.EXE
   Yarn: 1.16.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
   npm: 6.14.6 - C:\Program Files\nodejs\npm.CMD
   npmPackages:
   react-native: 0.62.2 => 0.62.2
   react-native-windows: 0.62.2 => 0.62.2
   Installed UWP SDKs:
   10.0.14393.0
   10.0.17134.0
   10.0.17763.0
   10.0.18362.0
3. reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock
   AllowDevelopmentWithoutDevLicense REG_DWORD 0x1
   AllowAllTrustedApps REG_DWORD 0x1

• Target Platform Version(s): 10.0.18362
• Target Device(s): UWP
• Visual Studio Version: Visual Studio 2019
• Build Configuration: Debug

Steps To Reproduce

Include an onMouseEnter and/or onMouseLeave property in a TouchableHighlight component.
The events will not fire.

You can also see this in the mouse.tsx sample in the Playground when you mouseover the child content. It does not highlight. It used to highlight in 0.60.

Expected Results

We are seeing this in our migration from the 0.60 branch to the 0.62 branch. We use TouchableHighlights throughout our app to provide mouseover styling. We expect these events to fire as they did in 0.60.

Problem:

These events are blocked by the new mouseEventHandlers in the Pressability class that expose the onHoverIn/onHoverOut events. This was part of the change in #4930

I have a potential fix out on my repo at https://github.com/KAnder425/react-native-windows/commit/fa92ecde3122a456fe1c07c91bdc819b147f3be1 The fix reenables the onMouseEnter/Leave events as a fallback if the onHover events are not handled. This fix resolves the issue with our app, but I don't know enough about how the onHover events are expected to behave to be confident about the change. For instance, should both events be sent, or just one or the other?

[NickGerleman]

Thank you for finding this.

This issue gets a bit hairy. RN 0.62 added Pressability as the foundation for creating views with press interaction (including Pressable in 0.63 which roughly succeeds Touchable). My limited understanding was that mouse event typings were added to react-native core for react-native-web, and Pressability added hover support using these events for react-native-web. These event handlers conflict with ours and eat events that were previously exposed, like you mention. The code added in the PR mentioned was forking Pressability to add keyboard activation from previous forked code in Touchables, since 0.62 refactored Touchable internals to use Pressabiltiy. Interestingly react-native-web doesn't seem to use onHoverIn in Pressability config anywhere, so I'm not sure what the history behind it is (@TheSavior do you know more?). It does still exist in core though and is exposed to anyone using Pressability directly in react-native-web.

Short-term, we did break existing behavior without documenting it or adding an alternative, and we should address it. Preserving compatibility likely looks like adding events to Pressability + Touchables, like what your PR does. Longer-term, we need to do something better. iPadOS, MacOS, and web all have mice and the same class of issues. It's likely anything we introduce to Windows only will end up conflicting with the community, or breaking as upstream changes happen (similar to what happened with Pressability).

We should really explore attacking mouse events and hover state styling in a more general way in core. E.g. having core formally expose MouseEvents, adding hover state to style functions on Pressable, adding hover state to default controls, etc. @harinikmsft and @acoates-ms have been looking at keyboarding, but I'm not sure we've tried looking at mouse interaction yet.