Re: xwidget events

[Aiko Kyle <aikokyle@gmail.com>]

On Sat, Oct 30, 2021 at 7:13 AM Po Lu <luangruo@yahoo.com> wrote:
>
> I've been experimenting with making xwidget-webkit on X11 usable as an
> actual web browser.  So far I've figured out the annoying redraw issues
> and the broken scroll optimization, but I'm still puzzling over event
> handling.
>
> I was able to borrow a Mac from a friend today for an hour or so, and I
> used it to try the NS xwidget implementation.  It seems to handle mouse,
> button and click events entirely separately from the rest of Emacs,
> which I don't think is a very good idea either.  But that also means the
> browser is actually useful, which is a good thing.
>
> In the existing X11 xwidget implementation, only some events, such as
> motion events are passed through (without being exposed to Lisp code
> first), while with the improvements to xwidget redisplay in bug#51473,
> no events are passed through to the xwidget at all.
>
> So I think a better idea would be the ability to pass through individual
> input events via Lisp code (for instance with a function named
> `xwidget-do-event', which would accept a lispy event as input and then
> send an equivalent event to the xwidget).  Lisp code could then take
> input events in the xwidget-webkit, and then send them to the xwidget.
>
> But that's my take as a relative outsider to Emacs input, so someone
> probably has a better idea.
>
> Any thoughts?  Thanks.

Sorry I haven't had the time to look over what you've done. I'm quite
interested, but unfortunately have very limited time these days.

In emacs-webkit, I introduced an "insert" mode to allows one to pass
keyboard events directly to webkitgtk's widget. This is done by
focusing the webkitgtk widget so gtk passes input events directly to
it and emacs does not receive them. I did this since I thought it was
very bad UI to see one's cursor on a web text field, try to interact
with it, and have nothing happen. I know xwidgets has this injected JS
workaround that allows one to type in the emacs minibuffer and send
the text to the html field. However this won't work to, say, tab
between form fields or use arrow keys to make selections. I'm not sure
how you'd extend the JS solution to handle all these cases generally.

On keyboard events, there will always be a tension between the CUA
keys that webkit is hardcoded to use and emac's keys. Someone could
write the appropriate translation layer, but it'll be a nontrivial,
likely manual, task and will require constant upkeep as these things
evolve in webkitgtk. Personally as an evil and former exwm user,
making keyboard focus a modal distinction is natural.

On mouse events, I'm not sure what you will gain by exposing such
events to lisp first then passing them to webkit. Is there some use
case this would enable? I can't imagine it being very helpful without
lisp also knowing what DOM element the mouse event is associated with.
I would also be worried about latency with the additional redirection.
Additionally, until emacs learns to handle xinput 2 type events, you
might risk losing all the multitouch gestures that webkit supports
including smooth two-finger scrolling.