Web: Pointer Cleanup

[daxpedda]

Changes

• Consistently send WindowEvent::CursorMoved before pressing or releasing a mouse button.
• Modifiers are now updated on touch events as well.
• Dropping support for versions of Safari below 13. See Remove mouse event fallback #2837 for more details notes.
• Fixed text selection by double-clicking or dragging on the canvas on Chrome (apparently not an issue on Firefox).
• Gaining and losing focus on touch now works properly.
• Add support for the pointerrawupdate event, to allow getting pointer updates as fast as possible.

Questions (obsolete)

All questions were already answered, just leaving it here for reference.

Contextmenu

I found that opening context menus can't be completely prevented on Firefox, because they provide a way to bypass any prevention method: Shift+Rightclick. I feel like Winit could document this somewhere, like at WindowBuilder::with_prevent_default().

WDYT?

Some notes on this:

• Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=897379.
• WHATWG spec:

  User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu.

• Was removed in Remove the context menu feature whatwg/html#2742. See Removal of context menus spec also removed possibility contextmenu event bypass whatwg/html#6433 and New contextmenu event definition missing bypass w3c/uievents#336.

Touch

The Web standard fires focus/blur as soon as touch starts and ends, but on Web we currently ignore this and you never get any WindowEvent::CursorEntered/Left on touch. How do other backends handle this?

High Frequency Pointer Input

I added support for pointerrawupdate, which is basically the same as pointermove but sends an event as soon as it arrives, instead of coalescing multiple events into one. I believe this aligns more with how other backends work. Does that sound alright?

[kchibisov]

The Web standard fires focus/blur as soon as touch starts and ends, but on Web we currently ignore this and you never get any WindowEvent::CursorEntered/Left on touch. How do other backends handle this?

CursorEntered/Left are only for pointer, touch doesn't really have such concept in my opinion and we don't have a backend doing any of that for touch. With touch you simply press on a window without moving any logical resource, the user can click in any point of the screen, so the only thing matters is point of click and release of the touch slot.

I added support for pointerrawupdate, which is basically the same as pointermove but sends an event as soon as it arrives, instead of coalescing multiple events into one. I believe this aligns more with how other backends work. Does that sound alright?

yeah, the events are usually send as soon as possible on other backends.

Modifiers are now updated on touch events as well.

Do they simply attached to the touch events as well on the web? Usually touch input is done without any sort of keyboard input at the same time, because, you know, you use your hands... Though, maybe I don't understand something and a concept of Touch + Shift exists.

Not sure what other input you've requested on irc.

[daxpedda]

Do they simply attached to the touch events as well on the web?

Yeah, they simply attach, it has nothing to do with the actual touch input. We just use it to figure out what modifiers are active after we regain focus. This works because PointerEvent inherits MouseEvent ... it's pretty weird.

Not sure what other input you've requested on irc.

No that's it, no more open questions, thank you very much 👍!

[daxpedda]

Apologies ... I meant to squash this actually.

[cybersoulK]

@daxpedda removing MouseHandler is a huge downgrade for game developers. Currently it's the only decent option for games. PointerHandler doesn't allow pressing both left and right at the same time (or any other press including the wheel), and if they do, the previous release events don't trigger anymore (only the last button press will)

[cybersoulK]

I think that might be a bug in the winit PointerHandler implementation itself? because i remember running a demo of javascript pointer and it worked as intended.

[daxpedda]

Indeed, the initial implementation didn't handle chorded buttons. This was addressed in #2838.
If you try the latest master it should work just fine.

Let us know if you encounter any issues!

[cybersoulK]

@daxpedda
i am using winit = { git = "https://github.com/rust-windowing/winit" }
but it seems to have the same behaviour as the previous Pointer.

Wow i am excited to see it being worked on. let me know what i can do to help.

[daxpedda]

That's strange, I just tried it, works perfectly on Firefox, Chrome and Safari.

Did you make sure you are at the tip with cargo update -p winit?
What browser and OS are you using?
What exactly are you trying? Step by step if you please.

[cybersoulK]

@daxpedda you are right! It works fine with Firefox and safari.

The Issue is only in: Chome (Mac) Version 114.0.5735.106 (Official Build) (arm64)

I am also having a new issue now on firefox (Mac) that mousemove seems to be buggy (my character looks at the ground very fast, and can't be changed, perhaps very high positive numbers in delta.Y),

should i create a separate issue for each?

[cybersoulK]

@daxpedda The 2 issues happen on Windows too.

Chrome can't do chorded mouse buttons, firefox has a bug in DeviceEvent::MouseMotion

perhaps it could be because of pointerlock? Update: Yes! chrome bug is due to calling request_pointer_lock(). Firefox bug is not related.

forgot to reply:
Did you make sure you are at the tip with cargo update -p winit?
Yes i am

What exactly are you trying? Step by step if you please.
It's a custom engine so there is more things going on, but i narrowed it down to the pointer being locked. Please try to lock the pointer with your previous code and see if our tests agree.

[daxpedda]

Currently on Firefox delta reports are buggy, see the Bugzilla bug report, I fixed it in #2871.

Chrome fails with chorded buttons when the pointer is locked. So I will have to investigate that.

But that's all I found, if there is anything else it would be really useful to provide a step-by-step instruction on how you reproduce the issue and on what browser and OS.

[daxpedda]

So apparently Chrome has some bugs with pointerrawupdate:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1289683
  No chorded buttons when the pointer is locked.
• https://bugs.chromium.org/p/chromium/issues/detail?id=1068958
  Wrong positions when in an inline frame.

I think I will rip it out completely until these issues are fixed, otherwise it's kind of unusable.

[cybersoulK]

@daxpedda yea that was it! it works perfectly now. Thank you so much, i was dealing with this for about a year.

firefox deltas still seems buggy, as of the current master branch

[daxpedda]

firefox deltas still seems buggy, as of the current master branch

This is fixed in #2871, but I will actually split off the fix.

[cybersoulK]

great! awesome, thank you for your great work!