Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fcffec75c21506c0bf8ba4fc89790ffd07c91f5a
https://github.com/WebKit/WebKit/commit/fcffec75c21506c0bf8ba4fc89790ffd07c91f5a
Author: Richard Robinson <[email protected]>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm
Log Message:
-----------
[AppKit Gestures] Changing selection on PDFs that are <object> or <embed>
sometimes does not work
https://bugs.webkit.org/show_bug.cgi?id=313954
rdar://172055860
Reviewed by Abrar Rahman Protyasha.
WKTextSelectionController results in `WebPage::setSelectionRange` and
`WebPage::updateSelectionWithExtentPointAndBoundary`
being called when clicking and dragging to change a selection.
Those entry points in addition to
`WebPage::updateFocusBeforeSelectingTextAtLocation`
look up the plugin via WebPage::focusedPluginViewForFrame(LocalFrame&), which
only
recognizes plugins whose host document is a PluginDocument.
PluginDocument is created only when a PDF is the main resource of a frame (see
DOMImplementation.cpp). `<iframe src=".pdf">` qualifies: the iframe's subframe
loads the PDF as its main resource, so its document is a PluginDocument.
`<embed>` and `<object>` do not: the plugin is an inline widget inside a regular
HTMLDocument, so the lookup returns nullptr, and this path falls through to
the generic HTML range-selection code, and the FrameSelection on an HTMLDocument
that only contains a widget node cannot produce a selection.
The synthetic-click path in WebPageCocoa already handles this case via
HTMLPlugInElement::pluginWidget(), which returns the PluginView uniformly for
all three hosting modes. Apply the same pattern to the two sites this bug
touches:
* WebPage::focusedPluginViewForFrame: if the frame's document is not a
PluginDocument, fall back to the document's focused element; if it is an
HTMLPlugInElement whose pluginWidget() is a PluginView, return that. The
existing PluginDocument branch is preserved.
* WebPage::updateFocusBeforeSelectingTextAtLocation: when the hit-test lands
on an HTMLPlugInElement (embed/object), call focusPluginElement() on its
PluginView so the fallback above can find it on subsequent lookups. The
iframe branch (pluginViewForFrame, which stays PluginDocument-only) is
unchanged.
Widening focusedPluginViewForFrame does intentionally affect its other callers
as well. populateEditorStateIfNeeded and executeEditingCommand now route to
embed/object-hosted PDFs when they are focused, so editor state and editing
commands like Copy and SelectAll behave consistently with iframe-hosted PDFs.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::updateFocusBeforeSelectingTextAtLocation):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::focusedPluginViewForFrame):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm:
(TestWebKitAPI::runSelectAllAndVerifySelectedTextMatches):
(TestWebKitAPI::UNIFIED_PDF_TEST):
Canonical link: https://commits.webkit.org/312734@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
