Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8828f24e7c4da08c591a057765bcdfed5bb05f00
https://github.com/WebKit/WebKit/commit/8828f24e7c4da08c591a057765bcdfed5bb05f00
Author: Aakash Jain <[email protected]>
Date: 2026-03-14 (Sat, 14 Mar 2026)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/UnifiedPDFTests.mm
Log Message:
-----------
Panning a PDF frequently gets into a state where it rubber bands back to
where you started
https://bugs.webkit.org/show_bug.cgi?id=309596
rdar://156854435
Reviewed by Abrar Rahman Protyasha.
When a full-frame PDF plugin on iOS delegates scrolling to the main frame,
the plugin's own UIScrollView should have no scrollable area.
However, expandedIntSize rounding in contentsSize() can produce a width 1 pixel
larger than the plugin's visible width. This makes the plugin's UIScrollView
horizontally scrollable, causing it to capture pan gestures and rubber-band
instead
of letting the main frame handle horizontal scrolling.
This is a regression from 290778@main (d8546c304004), which removed the
explicit CSS
width synchronization between contentsSize() and the plugin element. Without
that
synchronization, the rounding difference between expandedIntSize (ceilf) and the
CSS layout width becomes observable.
Fix by setting contentsSize().width() to the plugin's visible width when
shouldSizeToFitContent() is true, since in this mode the contents width should
always equal the plugin width.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::contentsSize const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/UnifiedPDFTests.mm:
(TestWebKitAPI::TEST): Added an API test.
Canonical link: https://commits.webkit.org/309264@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
