Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: dbc31d00f78f65a47f81c481e2eea008d13ef588
https://github.com/WebKit/WebKit/commit/dbc31d00f78f65a47f81c481e2eea008d13ef588
Author: moggiesir <[email protected]>
Date: 2023-01-28 (Sat, 28 Jan 2023)
Changed paths:
M Source/WTF/wtf/glib/GUniquePtr.h
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h
Log Message:
-----------
Fix async scroll event propagation for GTK4
https://bugs.webkit.org/show_bug.cgi?id=243924
https://bugs.webkit.org/show_bug.cgi?id=245616
Reviewed by Michael Catanzaro.
Since GTK offers no way to asynchronously decide on whether an event should be
propagated or stopped and webkit doesn't want to block the UiProcess on event
handing in the WebProcess, webkit2gtk needs to use a bit of a hacky workaround.
This involves returning GDK_EVENT_STOP to the original event handling, sending
the event to the WebProcess for handling, which then asynchronously determines
whether the event was handled. If not, the webkit scroll handler is informed
that the "next" scroll event should be propagated instead of handled+stopped,
then re-emits the event for handling by GTK's run loop.
This works fine in GTK3 because there's an API to immediately run the event
loop for a given event (ensuring that the next event that the handler sees is
the intended one). For GTK4, the API for re-inserting an event appends the event
to the end of the event queue (despite what the documentation says), meaning the
next event the handler sees may not be the intended event - thus the wrong event
gets propagated and the just re-added event gets sent to the WebProcess again.
This coupled with the fact that GDK4 will synthesize scroll-start/scroll-end
events in some cases to ensure scroll events allows have the scroll-start,
scroll, scroll-end sequence can easily cause loops since it's not just 1 event
that needs to be propagated, it's up to 3.
To work better with the APIs that exist for GTK4, it seems like the best option
is to track the set of events that are "pending propagation" instead of relying
on the tight interlock of just ignoring the "next" event. The key handling
potentially also needs to be addressed similarly. Unfortunately, even tracking
the set of events to ignore is challenging because GTK4 can compress/coalesce
scroll events, meaning there will inevitably be some cases where we won't
propagate events that otherwise maybe should have been propagated (and
"unhandled" scroll events may cause some faster/slower than expected scrolling
when they get compressed into an not-yet-handled events).
Canonical link: https://commits.webkit.org/259530@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
