Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 931bf0326ed7683d24a33afe2590e39c6f843790
https://github.com/WebKit/WebKit/commit/931bf0326ed7683d24a33afe2590e39c6f843790
Author: Abrar Rahman Protyasha <a_protya...@apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
[macOS] espn.com: Fullscreen video progress bar marker follows the cursor
https://bugs.webkit.org/show_bug.cgi?id=283184
rdar://133321873
Reviewed by Wenson Hsieh.
The video element on espn.com uses a mouseUp event listener on the
progress bar to deactivate its "scrubbing" mode. This works as expected
when the video element is inline, but breaks down when the video element
is fullscreened, and manifests itself as the cursor following the
progress bar marker.
When the video element is both in fullscreen and paused/seeked,
WebFullScreenManager thinks it is safe to begin text recognition, and
thus installs an image analysis overlay on the web view. When a user
then clicks on the progress bar (or starts dragging it), AppKit
performs hit testing during mouseDown event handling and remembers that
the overlay view is the view to route future mouse events (drag/up) to.
This is fine because the VKC views know how to re-route mouse events
to the web view when necessary. However, while this is happening,
espn.com marks their fullscreen video element as seeking, so
WebFullScreenManager ends text recognition and schedules an overlay
uninstallation. This overlay uninstallation causes the associated VKC
view to detach from the view hierarchy, and the hit tested view that
AppKit remembered to route events to no longer exists. Thus, when the
user finally releases their mouse, the resultant mouseUp event gets
routed to a null view, and the mouseUp event listener for the video
element does not fire.
We fix this issue by enforcing the invariant that any kind of view
hierarchy maintenance associated with the image analysis overlay cannot
happen while a mouse press is active. Deferring these tasks means that we
don't unexpectedly alter the view hierarchy under AppKit's event routing
path. This is safe to do because the VKC views appropriately re-route
events to the web view, unless their is an active text recognition
selection.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::mouseUp):
(WebKit::WebViewImpl::ensureImageAnalyzer):
(WebKit::WebViewImpl::requestTextRecognition):
(WebKit::WebViewImpl::beginTextRecognitionForVideoInElementFullscreen):
(WebKit::WebViewImpl::cancelTextRecognitionForVideoInElementFullscreen):
(WebKit::WebViewImpl::installImageAnalysisOverlayView):
(WebKit::WebViewImpl::uninstallImageAnalysisOverlayView):
(WebKit::WebViewImpl::performOrDeferImageAnalysisOverlayViewHierarchyTask):
Canonical link: https://commits.webkit.org/286840@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
