Fix scrollbars when pointer capture is released

[DJMcNab]

Fixes #857

cc @PoignardAzur - I don't know that the model for pointer capture is entirely coherent from a widget's perspective at the moment. In particular, since any widget can call release_pointer at any time, and there's no way for the widget with pointer capture to know.

I'm also not certain that other widgets don't have this same issue. I do think something in our model might need to be refined slightly here.

[jaredoconnell]

This PR does what you intended for it to do. However, the behavior isn't how users may expect it to work. For example, if I drag a scrollbar in a web browser, I can keep holding the click while dragging outside of the window, and the scrollbar will continue to follow my cursor on the appropriate axis.
In this situation, it just loses attachment when you leave the bounds of the window. In the prior code if you went back in the window it would continue being attached in a broken way, but would not update outside of the window.

Would the current design allow for dragging while the cursor is outside of the window, or would further changes be required to make that work?

[DJMcNab]

In this situation, it just loses attachment when you leave the bounds of the window. In the prior code if you went back in the window it would continue being attached in a broken way, but would not update outside of the window.

This isn't the behaviour on my machine. As far as I know, this is how we describe this in the API we have now.
It seems like there might need to be a fix on winit's side for your platform?

[PoignardAzur]

In particular, since any widget can call release_pointer at any time, and there's no way for the widget with pointer capture to know.

That seems like an oversight on our part. A widget should only be able to release its own capture status.

[PoignardAzur]

Testing both the main branch and this PR, I agree that our current model of pointer capture doesn't work, and especially the fact that we remove capture on PointerLeave.

Honestly I'm not sure I had a good model of how winit worked when I coded that. I think I was thinking of WindowEvent::CursorLeft as "the cursor disappeared" when the proper event to represent that is probably DeviceEvent::Removed.

This PR works as a band-aid to be less inconsistent in this case, but we'd probably want to keep pointer capture even when the pointer leaves the window rect.

[PoignardAzur]

At this point I wonder if we should add an Update::PointerCaptureChanged event.

[DJMcNab]

I think the relevant event is most likely Focused. When that's sent, we will definitely never get the mouse up event? I'm not certain.

I'm happy to close this if you don't think it's an improvement.

[PoignardAzur]

Let's leave it open. We'll merge it if we haven't had a better fix before the end of the month.