Repository navigation
[Writing Flow regression in 7.1] Down arrow key navigation fails to auto-scroll viewport when post title is visible #82839
Description
Description
In WordPress 7.1, traversing downwards through paragraph blocks using the Down Arrow (↓) key fails to auto-scroll the canvas when the post title is visible in the viewport (scrollTop = 0). The caret hits the bottom boundary of the screen and gets locked.
Key contrast: Once the post title is scrolled out of view manually (e.g., via mouse wheel), the exact same Down Arrow navigation auto-scrolls smoothly as expected.
Expected behavior
The editor viewport should automatically scroll down following the caret across blocks, regardless of whether the post title is currently visible.
Actual behavior
The caret is trapped at the bottom edge of the visible screen. No scroll event is triggered until a manual scroll action (wheel or trackpad) pushes the title off-screen.
This is a critical writing flow regression introduced in 7.1 (verified working properly in 7.0.4 and 6.9.7 under identical conditions).
Step-by-step reproduction instructions
- Set up a clean WordPress 7.1 test environment with the Twenty Twenty-Five theme (no third-party plugins).
- Create a new post, enter a title, and insert 15–20 Paragraph blocks filled with text.
- Keep the editor at the very top so the post title is clearly visible (
scrollTop = 0). - Place the caret inside the first Paragraph block.
- Press and hold the Down Arrow (↓) key to traverse down through the blocks.
- Observe: As soon as the caret reaches the bottom edge of the visible screen, scrolling halts completely and the caret is blocked.
- Verify workaround: Scroll down slightly with the mouse wheel so the title leaves the screen, then press Down Arrow (↓) again — auto-scroll resumes normally.
Screenshots, screen recording, code snippet
WP7.1.mp4
Environment info
- WordPress version: 7.1 (Confirmed regression from 7.0.4 / 6.9.7)
- Gutenberg plugin: Not installed (WordPress Core block editor only)
- Theme: Twenty Twenty-Five (Clean default installation)
- Browser: Google Chrome (Latest)
- OS: Windows 11
- PHP: 8.5
Please confirm that you have searched existing issues in the repo.
- Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
- Yes
Please confirm which theme type you used for testing.
- Block
- Classic
- Hybrid (e.g. classic with theme.json)
- Not sure
Activity
hbhalodia commentedon Sep 14, 2026
Hi @kurikimuchi, Thanks for the report. I tried to reproduce it with WordPress Playground with 7.1 version and I am unable to replicate the issue. Please check the below screencast. I have followed the steps mentioned in the ticket.
Screen.Recording.2026-09-14.at.7.17.57.PM.mov
Adding a
needs testinglabel so contributors can test and we can take the ticket forward.Thanks,
kurikimuchi commentedon Sep 15, 2026
Hi @hbhalodia ,
Thank you for testing and adding the
needs testinglabel!I checked your screen recording. Upon further testing, I noticed an important additional detail regarding the behavior:
It seems the editor canvas fails to trigger
scrollIntoView(or its equivalent container scroll event) during keyboard navigation on Windows/Chromium.Looking forward to seeing results from other contributors testing on Windows 11 / Chrome. Thanks again!
Mayank-Tripathi32 commentedon Oct 7, 2026
Hi @kurikimuchi
I tried to reproduce this on current trunk (macOS, Chrome) with the steps above: Twenty Twenty-Five, 20 multi-line paragraphs, holding ↓ from the first paragraph. I also tried 100/125/150% display scaling, several viewport sizes and always-visible scrollbars, but the caret always reached the last block and the canvas scrolled with it.
One change in 7.1 that could explain a Windows-only difference is #80708, which added an early exit to
isEdgein@wordpress/domwhen the block's edge is outside the viewport. If the last line is visible but the block's bottom padding is just below the viewport, it could report "not at the edge" and leave the caret stuck.@kurikimuchi, a few details would help narrow it down:
I will also look into trying to reproduce this on my windows machine to pinpoint the cause in the meantime.
kurikimuchi commentedon Oct 7, 2026
Hi @Mayank-Tripathi32
Thank you for the detailed follow-up! Here are the results from testing in my environment:
Windows Display Settings:
Single-line paragraphs:
Browser zoom (90% / 110%):
Hope this helps narrow down the issue! Please let me know if there are any other checks or details you need.
robelsust commentedon Oct 15, 2026
I have investigated the root cause and submitted a fix in PR #84800.
As @Mayank-Tripathi32 noted, the issue stemmed from the early exit in
isEdgeintroduced in #80708: for single-line paragraphs near the bottom of the viewport, the text line sits just inside the viewport while the bottom boundary/padding extends slightly pastinnerHeight. Even though the distance is only a few pixels,isFarFromVerticalEdgeevaluated totrue, reporting that the caret was not at the edge and trapping arrow navigation.The PR:
isEdgeto containers taller/wider than the viewport where the selection is far from the probed edge, preserving the Unintended scrolling when editing inside tall blocks (long paragraphs, long quotes, or tall table cells) — caret moves but editor scrolls unpredictably #73801 fix while restoring smooth auto-scroll navigation for standard blocks.scrollIfNoRange.