Add cursor grab for web target

[TotalKrill]

• Tested on all platforms changed patched winit, tried it in bevy_winit, works
• Compilation warnings were addressed cargo build --target wasm32-unknown-unknown
• cargo fmt has been run on this branch
• cargo doc builds successfully
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[cwfitzgerald]

I have implemented this independent of winit, and enabling pointer grab causes this call to throw a nasty error: https://github.com/rust-windowing/winit/blob/master/src/platform_impl/web/web_sys/canvas/pointer_handler.rs#L82-L84. We likely would need to disable this call when cursor grab is enabled.

scene-viewer.js:347 panicked at 'Failed to set pointer capture: JsValue(InvalidStateError: Failed to execute 'setPointerCapture' on 'Element': InvalidStateError

[TotalKrill]

Would not the correct way be to not have an expect in fallible code?

The other way is if we could accurately predict that the state was actually that the pointer is already locked, that would solve your specific case, but since I do not know which ways that the pointerlock function can fail, its not a very good fix.

I mean, unfortunately in web, elements are shared in an unsafe manner, making it hard to have full control. As you say, you can do JS calls on the element and rust code will not ( i believe ) have a chance to react to it?

[cwfitzgerald]

That sounds like a reasonable plan, I'll fork winit tonight and disable the expect to see what happens.

[cwfitzgerald]

@TotalKrill I just checked out your branch and disabled the expect there, and everything works as we expect. So with that one change I think this PR is ready to go.

[maroider]

So with that one change I think this PR is ready to go.

+ resolving the merge conflict for CHANGELOG.md

[TotalKrill]

Im actually not entirely sure just removing the expect, I rather dislike silent errors

Would a log::error! be okay to add after the set_pointer_capture() call? like this:

                let e = canvas.set_pointer_capture(event.pointer_id());
                if !e.is_ok() {
                    log::error!("{:?}", e);
                }

[cwfitzgerald]

The issue with a log is that the error will occur every single time you click the mouse when the cursor is grabbed. That would unnecessarily spam the logs. I don't think there's a situation where this could fail that we really care that it fails.

[TotalKrill]

I added a comment there and modified the commit message to be a bit more explicit

[maroider]

After coming back to this PR, I've come to the conclusion that the PR is fine as-is, although I'd like to test it myself before approving it.

[maroider]

Seems to work fine when I tested it.

[ArturKovacs]

Note that the chagelog entry will end up under the wrong release after merging.

I suggest merging the latest master into this branch and then moving your changelog entry to the topmost section.

[maroider]

I rebased the branch on top of master to get rid of the merge conflicts. Hope you don't mind :)

I'll merge this in a bit.

[TotalKrill]

I definitely don't mind, in fact I am thankful 👍