Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x11, wl: Fix mouse button indices #704

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aperezdc
Copy link
Member

@aperezdc aperezdc commented Apr 2, 2024

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:

  • The X11/XCB button numbers start at 1, so they need conversion to be 0-based.
  • The Wayland button numbers have the BTN_* values from the <linux/input-event-codes.h> header.

This PR fixes them accordingly.

In the XCB events the mouse buttons start at index 1, while for WPE we
need to use 0-based indexing: buttons [left, middle, right] are [1, 2,
3] in X11, [0, 1, 2] in WPE.
@aperezdc aperezdc added the bug Something isn't working label Apr 2, 2024
@aperezdc aperezdc self-assigned this Apr 2, 2024
Handle the first five pointer buttons by checking their exact
button codes. Their values are used directly to avoid the need
for <linux/input-event-codes.h> to be present at build time.
@aperezdc aperezdc force-pushed the aperezdc/button-event-fixes branch from 0666394 to 1ff8267 Compare April 2, 2024 23:25
@aperezdc
Copy link
Member Author

aperezdc commented Apr 2, 2024

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.

@aperezdc aperezdc marked this pull request as ready for review April 2, 2024 23:27
@vrazzer
Copy link

vrazzer commented Apr 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants