Reset cursor position after app update

[mockersf]

Objective

• CursorLeft events reset the cursor position immediately
• This is an issue if there are other events in the same frame as the position is cleared before those events are read by user code
• Fixes Touch release input not working on WASM/Web #3752

Solution

• Reset the position after the app update.This fix the case I'm interested in: https://w3c.github.io/pointerevents/#the-pointerup-event
  • pointerup events, which winit uses to trigger MouseInput events for mouse button up, are immediately followed by a pointerout event on browser that don't support the "hover"
  • this means that on those browsers, mouse button up in Bevy don't have the cursor position available as it has been reseted at the start of the frame
  • most UI frameworks (at least, bevy_ui and bevy_egui) react on mouse button up events
  • so UI won't work on mobile in wasm

[cart]

Typically "resource state" is generated by processing all events since this update started in the order they arrive. The problem is that this "projection of event state" is lossy (ex: you cant find an intermediate position of the cursor, only the last position of the cursor). Resource state is provided as a way for users to query the "current state of a thing as of this frame" as a shorthand for regenerating the current state by processing events one by one. Up until now, if the intermediate state was required by the app, the solution was to consume events directly. Resource state == "easy to access and current as of this frame if you were to process all events in they order the arrived". Events == "harder to access current state, but gives you full access to the changes in the order they occur".

This change breaks a number of the assumptions above:

1. That the resource state is the current state. There is now one frame of lag when processing "pointerout" events.
2. That the resource state is the product of processing all events in order. Due to the lag, the resource state is out of sync with the event feed.

If there is no other solution to this problem, I'm open to considering this. But I'd like to solve (1) and (2) if we can.

[cart]

This appears to be resolvable by just handling the "no cursor position" case properly in the interaction handler. I think I have a working solution. Just testing edge cases now.

[mockersf]

This appears to be resolvable by just handling the "no cursor position" case properly in the interaction handler. I think I have a working solution. Just testing edge cases now.

I think handling it in the interaction handler could work only if you don't care where the mouse is when you have the mouse_up event.

[cart]

I think thats already the case right? Isn't that desirable behavior?

[mockersf]

For drag and drop or selection, if you don't use the cursor position on button up, it means you have to keep an internat state of where the cursor was last seen.

[cart]

Hmm that might be something we want to provide then (we do already track this, so we could have a "last cursor position" on windows). Introducing information lag in the interest of specific scenarios feels wrong to me.

[cart]

I'll create a new PR that handles the "no cursor position" correctly in the interaction handler. It will also fix another bug on wasm that leaves the button pressed when a click press results in a scroll (present both in this PR and in my interaction fix).