Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d7534d72ebb03f112ce4002fd5e2b437ae25d2d8
https://github.com/WebKit/WebKit/commit/d7534d72ebb03f112ce4002fd5e2b437ae25d2d8
Author: Wenson Hsieh <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
A
LayoutTests/fast/scrolling/ios/keyboard-scrolling-subscrollable-with-input-expected.txt
A
LayoutTests/fast/scrolling/ios/keyboard-scrolling-subscrollable-with-input.html
M Source/WebKit/UIProcess/ios/WKKeyboardScrollingAnimator.mm
Log Message:
-----------
[iPad] Unable to scroll using arrow keys in sub-scrollable region after
pressing arrow keys in a focused text field
https://bugs.webkit.org/show_bug.cgi?id=301240
rdar://152188882
Reviewed by Abrar Rahman Protyasha and Tim Horton.
Currently, on chatgpt.com, if you:
1. Focus the chat box and press any of the arrow keys
2. Tap the chat transcript
3. Try to use arrow keys to scroll the transcript
...the transcript fails to scroll, despite it being an overflow scrolling
container. This happens
because we first set `_scrollView` here in `WKKeyboardScrollViewAnimator` after
pressing an arrow
key in the input field, on the line marked by (1):
```
- (BOOL)beginWithEvent:(::WebEvent *)event scrollView:(WKBaseScrollView
*)scrollView
{
if (!_scrollView)
_scrollView = scrollView; // <----- (1)
if (_scrollView != scrollView)
return NO; // <----- (4)
return [_animator beginWithEvent:event]; // <----- (2)
}
```
However, when we actually try to `-beginWithEvent:` at (2), we fall down the
early return (3) below:
```
- (BOOL)beginWithEvent:(::WebEvent *)event
{
if (event.type != WebEventKeyDown)
return NO;
auto scroll = [self keyboardScrollForEvent:event];
if (!scroll)
return NO; // <----- (3)
…
}
```
...and don't actually begin scrolling. This means that we never end up clearing
the `_scrollView` in
`-didFinishScrolling`, and `_scrollView` is stuck pointing to `WKScrollView`.
Later, when `-beginWithEvent:scrollView:` is invoked with the child scroller,
we end up bailing at
the line marked (4) above, and never begin scrolling. To fix this, we reset
`_scrollView` to `nil`
in the case where keyboard scrolling failed to actually begin as a result of
the keypress, such that
it will be set to the child scroller the next time the user attempts to trigger
keyboard scrolling
again after tapping inside the child scroller.
Test: fast/scrolling/ios/keyboard-scrolling-subscrollable-with-input.html
*
LayoutTests/fast/scrolling/ios/keyboard-scrolling-subscrollable-with-input-expected.txt:
Added.
*
LayoutTests/fast/scrolling/ios/keyboard-scrolling-subscrollable-with-input.html:
Added.
Add a layout test to exercise the fix.
* Source/WebKit/UIProcess/ios/WKKeyboardScrollingAnimator.mm:
Make `-beginWithEvent:` return a more descriptive enum type describing how the
request to begin
keyboard scrolling was handled; only clear out `_scrollView` in the case where
the key event itself
does not trigger scrolling at all (not because scrolling is already in progress
and the triggering
key is still pressed, or because the scroller is not rubber-bandable). See
above for more details.
(-[WKKeyboardScrollingAnimator beginWithEvent:]):
(-[WKKeyboardScrollViewAnimator beginWithEvent:scrollView:]):
Canonical link: https://commits.webkit.org/301929@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
