Add edge delay before wrapping to another edge/display

[mikehall-ms]

Summary of the Pull Request

This PR adds a new option for a delay before wrapping to another monitor edge, this feature can be enabled/disabled, and supports delays of 250ms to 1000ms.

PR Checklist

• Closes: [CursorWrap] Add resistance option for wrapping #44855
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Adds a delay before transitioning to another display, this allows the user to 'bump' the edge of the display when aiming for an applications system menu, browser tabs, close button, system tray, etc... default delay is 250 ms - if the user moves the mouse during the delay period then the timeout is cancelled.

Validation Steps Performed

Confirmed behavior on Surface Laptop 7 Pro with USB-C external monitor.

[daverayment]

Hi @mikehall-ms. I think there are a few UX-related issues with the time delay approach. Although it solves the issue where the screen edges cannot be touched at all, I think it could introduce some new problems:

1. Fitt's Law is still broken because the screen edges are "lava". Fitt's Law means that border and corner elements are easier to hit, and users can quickly and confidently move to a maximised window's close button, a scrollbar at the screen edge, or the Windows Start button without having to be exact. (Some software like remote desktop, Mouse Without Borders and virtual machines use the border as a trigger to hide the mouse cursor or show a menu, too.) Unfortunately, with CursorWrap, leaving your mouse cursor at the border will wrap you to the opposing edge or the next monitor. With the old code, the warp is instantaneous, meaning the borders are untouchable. This PR gives the user chance to cancel the wrap behaviour by moving away within the time delay, but I'd argue that it's not very intuitive and the default 250 millisecond delay means mistakes are very easy to make.
2. The Windows Taskbar with auto-hide enabled is still an issue. This has been raised several times - see [CursorWrap] Conflicts with taskbar Auto Hide capability #44827. Currently, having the Taskbar in this mode is essentially incompatible with vertical wrap because the Taskbar "unhide" area conflicts with the CursorWrap trigger.
3. There's new anxiety about screen edges. With the time delay, users have to act differently around the screen edges. An accidental bump has to be counteracted immediately or they end up on the other side of the screen or on the neighbouring monitor. If the user increases the delay to try to prevent accidental triggering, they are punished if they do get it wrong, as it's longer to correct their mistake. The screen edges should be predictable and not require second-guessing and finessing your movemnet. Also see [CursorWrap] Add resistance option for wrapping #44855 for more context.
4. Accessibility concerns. This is probably the most significant to be honest. Staying perfectly still for the time delay will prove challenging for those with motor control difficulties. Currently, any movement will reset the timer. I notice there's an option in the code called s_allowWobbleTolerance which isn't exposed yet, so this is likely something you've considered already. Beyond the motor control challenges, there's the element of time pressure which this introduces, which some may find difficult (that "edge anxiety" I mentioned above).

I think there's an alternative approach which is superior. I've been working on this for a little while and it centres around "sticky edges" with push-through resistance replacing the current "border warp" behaviour.

Instead of wrapping after a time delay, the user would have to actively push through the edge for a configurable distance (e.g. 25 pixels, but scaled by the DPI of the current monitor).

How it works:

1. The cursor reaches the outer edge of the screen. The cursor stops at the edge and can stay there indefinitely.
2. If the user pushes in the direction of the border, a resistance value is accumulated. (Movement away from the edge resets the value or at least rapidly diminishes it - the sensitivity here may be configurable for accessibility purposes.)
3. After the preconfigured resistance has been pushed through, the wrap occurs.

I think this is superior because:

• Fitt's Law is (sort of!) respected. A user can fling their mouse to the edges or corners more easily (as long as they don't exceed that extra distance, they won't be wrapped). It's not an "infinite edge" as the law would dictate, but it's still beneficial.
• Hidden taskbar targets are restored. The bottom border can be interacted with more naturally.
• Much reduced edge anxiety. There must be clear intentionality in a user's actions because they have to "push through" to get the wrap to occur. Yes, a large fling would still wrap, but that could be corrected with the exact reverse action and there's never a case when a wrap would occur without movement on the user's part.
• The mental model of pushing through to get to the next monitor is more intuitive than the time delay, so I think it will be more comfortable and easier to learn.
• There should be fewer accidental wraps when pausing, clicking or resizing elements near the screen edges.

I don't want to sound pretentious, but I think the "intentionality" of this is the main thing that makes it a decent alternative.

The feeling is a little like haptic feedback, where there's an appreciable "bump" to the movement between screens. It's strangely pleasant.

OK, now I definitely sound pretentious.

I am part way through my implementation, but I'm happy to open a draft PR to share the current approach and maybe work together on a solution. (Or I'll back off if you think the time delay is your preferred approach - just let me know.)