WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
298992
Pan gestures pass through scroll containers laid over vertical-rl body text (but only once the document's scrollingElement has been scrolled by about one viewport of width)
https://bugs.webkit.org/show_bug.cgi?id=298992
Summary
Pan gestures pass through scroll containers laid over vertical-rl body text (...
Jamie Birch
Reported
2025-09-16 18:21:40 PDT
Created
attachment 476768
[details]
A repro for the issue. # About When the <body> element is styled as `writing-mode: vertical-rl`, scroll containers laid over that <body> element exhibit problems with: 1. scrolling (pan gestures pass through them to scroll the <body>); 2. rendering (they do not render at all). It depends on OS, OS version, and Safari version. # Scroll problems (iOS 18) In Safari on iOS 18.6.2 when panning via touch, we experience scroll problems. When you attempt to pan a <div> that is overflowing, it scrolls as expected, but only so long as the document's scrollingElement has not been scrolled far from its initial offset. Once you scroll the document's scrollingElement along a bit (e.g. past the initial viewport), it is no longer possible to scroll the overflowing <div>, as all gestures are intercepted by the <body> and only the body scrolls. Additionally, there may be rendering problems, with parts of the <div>'s scroll content disappearing (i.e. the text vanishes, leaving only the background colour to be seen) after the document's scrollingElement has been scrolled along a bit. Reproduction video on an iOS 18.1 simulator:
https://bsky.app/profile/shirakaba.bsky.social/post/3lyyn5ivlrk2u
Note that there are no scrolling problems in macOS Safari Version 17.6 (19618.3.11.11.5) when panning via a mouse or trackpad. # Rendering problems (macOS 26 and iOS 26) I tried running the same test on the latest Safari: macOS Tahoe 26.0 (25A353): - macOS Safari 26.0 (21622.1.22.11.14). - Safari on iOS 26.0. - macOS Safari TP 227 (WebKit 21623.1.5). In these environments, the scroll container didn't even render, so I couldn't even test scroll behaviour. Screenshot:
https://bsky.app/profile/shirakaba.bsky.social/post/3lyynmbvs6c2o
Attachments
A repro for the issue.
(13.79 KB, text/html)
2025-09-16 18:21 PDT
,
Jamie Birch
no flags
Details
A video of the scrolling issue on iOS 18.1.
(5.11 MB, video/mp4)
2025-09-16 18:23 PDT
,
Jamie Birch
no flags
Details
A video of the rendering issue (text vanishing) on iOS 18.1 when using a horizontal-tb overlay over a vertical-rl body.
(7.82 MB, video/mp4)
2025-09-16 18:24 PDT
,
Jamie Birch
no flags
Details
A screenshot of the scroll containers vanishing altogether on latest Safari.
(2.98 MB, image/png)
2025-09-16 18:25 PDT
,
Jamie Birch
no flags
Details
A video proving that the scrolling bug occurs only with vertical-rl text and not horizontal-tb.
(5.56 MB, video/mp4)
2025-09-16 18:32 PDT
,
Jamie Birch
no flags
Details
In iOS 26.2, a fixed-position <div> fails to render at all in `writing-mode: vertical-rtl`.
(3.33 MB, image/png)
2026-02-03 21:55 PST
,
Jamie Birch
no flags
Details
In iOS 26.2, the same fixed-position <div> renders correctly in `writing-mode: horizontal-tb`.
(3.35 MB, image/png)
2026-02-03 21:56 PST
,
Jamie Birch
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jamie Birch
Comment 1
2025-09-16 18:23:48 PDT
Created
attachment 476769
[details]
A video of the scrolling issue on iOS 18.1.
Jamie Birch
Comment 2
2025-09-16 18:24:39 PDT
Created
attachment 476770
[details]
A video of the rendering issue (text vanishing) on iOS 18.1 when using a horizontal-tb overlay over a vertical-rl body.
Jamie Birch
Comment 3
2025-09-16 18:25:59 PDT
Created
attachment 476771
[details]
A screenshot of the scroll containers vanishing altogether on latest Safari.
Jamie Birch
Comment 4
2025-09-16 18:29:18 PDT
Additionally, here is a video recording I took demonstrating that the problem occurs specifically with vertical-rl text and not horizontal-tb text:
https://bsky.app/profile/shirakaba.bsky.social/post/3lhvtwmr7fc2v
Jamie Birch
Comment 5
2025-09-16 18:32:09 PDT
Created
attachment 476772
[details]
A video proving that the scrolling bug occurs only with vertical-rl text and not horizontal-tb.
Simon Fraser (smfr)
Comment 6
2025-09-17 10:59:24 PDT
Thank you for the report!
Radar WebKit Bug Importer
Comment 7
2025-09-17 10:59:43 PDT
<
rdar://problem/160788907
>
Simon Fraser (smfr)
Comment 8
2025-09-17 12:59:57 PDT
I think I see (at least) three problems here, as you describe: 1. At various window sizes, the black overlay on
https://bug-298992-attachments.webkit.org/attachment.cgi?id=476768
is badly sized, or disappears 2. Missing text (unrendered tiles) occur with some configurations 3. Can't scroll the <div> after the body has been scrolled, with vertical-rl I'll split off additional bugs as I investigate.
Jamie Birch
Comment 9
2026-02-03 21:55:39 PST
Created
attachment 478244
[details]
In iOS 26.2, a fixed-position <div> fails to render at all in `writing-mode: vertical-rtl`.
Jamie Birch
Comment 10
2026-02-03 21:56:27 PST
Created
attachment 478245
[details]
In iOS 26.2, the same fixed-position <div> renders correctly in `writing-mode: horizontal-tb`.
Jamie Birch
Comment 11
2026-02-03 21:58:04 PST
Update: The behaviour is even worse in iOS 26.2, WebKit 605.1.15. Now, even when a `position: fixed` <div> is positioned in the initial viewport (in contrast to before, where you had to scroll to a certain offset to reproduce the issue), it doesn't render at all. Submitting two new attachments to illustrate: - `iOS 26-2 fixed-position div in vertical-rtl (fails to render).png` - `iOS 26-2 fixed-position div in horizontal-tb (renders correctly).png` The ability to render fixed-position elements in `writing-mode: vertical-rl` seems to regress more and more with each release of WebKit and continues to roadblock all my efforts to create an ebook reader app for Japanese ebooks, sadly. Could I ask whether any progress is being made on this?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug