Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8f6ed05e251aa77b72410e8dce3d62588bc32c93
https://github.com/WebKit/WebKit/commit/8f6ed05e251aa77b72410e8dce3d62588bc32c93
Author: Alan Baradlay <[email protected]>
Date: 2026-04-30 (Thu, 30 Apr 2026)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm
Log Message:
-----------
REGRESSION(312300@main): [macOS]
TestWebKitAPI.UnifiedPDF.EmbeddedPDFScrollbarDoesNotAdaptToDarkMode is flaky
failure
https://bugs.webkit.org/show_bug.cgi?id=313768
<rdar://problem/175961655>
Reviewed by Abrar Rahman Protyasha.
Restore pre-312300@main behavior, by only applying the page's dark mode
appearance to full-frame PDF scrollbars, not embedded ones.
Before 312300@main
For full-frame PDFs, the scrollbar appearance follows the system dark mode.
For embedded PDFs, it does not - the scrollbar always uses the default
appearance.
Codeflow before 312300@main:
return useDarkAppearance() || scrollbarOverlayStyle() ==
ScrollbarOverlayStyle::Light;
(and with no useDarkAppearance() override on PDFPluginBase -where base class
returns false)
Full-frame PDF, light mode:
1. useDarkAppearance() -> no override, base class -> false
2. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() set it
to Default since page->useDarkAppearance() was false)
3. Default == Light -> false
Result: false
Full-frame PDF, dark mode:
1. useDarkAppearance() -> no override, base class -> false
2. scrollbarOverlayStyle() -> Light (updateScrollbarOverlayStyle() set it
to Light since page->useDarkAppearance() was true)
3. Light == Light -> true
Result: true
Embedded PDF, light mode:
1. useDarkAppearance() -> no override, base class -> false
2. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() at
UnifiedPDFPlugin.mm bails out with
if (!isFullMainFramePlugin()) return - never sets overlay style)
3. Default == Light -> false
Result: false
Embedded PDF, dark mode:
1. useDarkAppearance() -> no override, base class -> false
2. scrollbarOverlayStyle() -> Default (same reason as above)
3. Default == Light -> false
Result: false
Codeflow after this fix:
Full-frame PDF, light mode:
1. useDarkAppearance() -> PDFPluginBase override ->
page->useDarkAppearance() -> false
2. Falls through to check #2
3. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() set it
to Default since page->useDarkAppearance() was false)
4. Default == Light -> false
Result: false
Full-frame PDF, dark mode:
1. useDarkAppearance() -> PDFPluginBase override ->
page->useDarkAppearance() -> true
Result: true
Embedded PDF, light mode:
1. useDarkAppearance() -> PDFPluginBase override -> base class
ScrollableArea::useDarkAppearance() -> false
2. Falls through to check #2
3. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() bails
out with
if (!isFullMainFramePlugin()) return -- never sets overlay style)
4. Default == Light -> false
Result: false
Embedded PDF, dark mode:
1. useDarkAppearance() -> PDFPluginBase override -> base class
ScrollableArea::useDarkAppearance() -> false
2. Falls through to check #2
3. scrollbarOverlayStyle() -> Default (same reason as above)
4. Default == Light -> false
Result: false
All four cases match the behavior before 312300@main. The only difference is
how full-frame dark mode works: before, it went through the overlay style path
(scrollbarOverlayStyle was set to Light); now it goes through
useDarkAppearance().
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::useDarkAppearance const):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm:
(TestWebKitAPI::UNIFIED_PDF_TEST):
Canonical link: https://commits.webkit.org/312409@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
