Bug 261230
| Summary: | Clean up overlay scrollbar logic on iOS | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | Scrolling | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 16 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Simon Fraser (smfr)
iOS has some old #ifdefs, like the one in RenderLayerScrollableArea::showsOverflowControls(), that essentially "turn off" scrollbars in WebCore, since it assumes that they are rendered in the UI process.
However, when canUseCompositedScrolling() returns false, like inside SVG <foreignObject>, then the code still tries to paint scrollbars, which does nothing.
Instead, we should fix ScrollbarThemeIOS to return true from `usesOverlayScrollbars()` and make the iOS code closer to the macOS UI-side compositing code.
Also, at some point, we should support resizes on iOS, which requires that we run code in RenderLayerScrollableArea::paintOverflowControls.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/115450826>