search

Igalia / cog

WPE launcher and webapp container
MIT License
241 stars 61 forks source link

x11, wl: Fix mouse button indices #704

Open aperezdc opened 7 months ago

aperezdc commented 7 months ago

Fix the X11 and Wayland plug-ins to pass the correct pointer button indices in wpe_input_pointer_event::button. The WPE values are based on the MouseEvent.button spec, and:

This PR fixes them accordingly.

aperezdc commented 7 months ago

Interestingly, having the correct values for the ::button member will cause WPE WebKit to stop processing mouse button events after the first time the right mouse button is pressed—the web view is still “alive” and e.g. scrolling or keyboard input works. This is a separate bug and likely somewhere in WebKit's input and/or context menu handling.

vrazzer commented 6 months ago

Are you certain wpe_input_pointer_event::button uses the zero-based MouseEvent button spec? This seems contrary to my experiences which suggest it is one-based. Digging through wpe-source reveals createWebMouseEvent() which uses a simplistic hard-coded 1=left, 2=right, 3=middle, all others ignored. Note that wpe_input_pointer_event::modifiers does correspond to the W3C spec with the correct bitmask values.

https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/3946d5a76cf0862ad75b5f8763e53bd031d26fb2/Source/WebKit/Shared/libwpe/WebEventFactory.cpp#L158

Can also confirm right-click (value == 2) messing up subsequent input. Had assumed it was related to using DRM (so no way to render a context-menu), but seems more fundamental. Tried lots fo work around it, but without luck. Input-field double-clicking and text selection also fail to work. This may be related to wpe button handling in that the "clickCount" field is always 0/1. That suggests the calling code is supposed to identify a double-click, but there is no way to actually do so.