WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 290576
287867
REGRESSION (iOS 18.0.1-18.3.1): Safari fullscreen video text track cues illegible size
https://bugs.webkit.org/show_bug.cgi?id=287867
Summary
REGRESSION (iOS 18.0.1-18.3.1): Safari fullscreen video text track cues illeg...
gglendinning
Reported
2025-02-18 10:06:20 PST
An issue has been introduced in iOS 18.3.1 which did not exist in iOS 18.0.1 in Safari. With an HTML5 video using HLS (m3u8 with vtt), subtitles are displayed incorrectly. Upon entering fullscreen, the subtitle size is minuscule, rendering at 5cqmin, which equates to ~1% of the video element height. This is critical for accessibility, as subtitles cannot be read in fullscreen video.
Attachments
Before overriding CSS
(43.78 KB, image/png)
2025-03-06 06:41 PST
,
gglendinning
no flags
Details
After overriding CSS
(67.59 KB, image/png)
2025-03-06 06:41 PST
,
gglendinning
no flags
Details
BipBop-subtitle-fullscreen
(479.13 KB, image/jpeg)
2025-03-06 15:18 PST
,
Jer Noble
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2025-02-19 10:08:51 PST
Thank you for the report! Would it be possible to provide a test case where we could observe the problem directly?
Radar WebKit Bug Importer
Comment 2
2025-02-19 10:09:11 PST
<
rdar://problem/145149369
>
Alexey Proskuryakov
Comment 3
2025-03-03 12:30:15 PST
We've been unable to reproduce the issue using
https://jernoble.github.io/samples/bin/WebVTT/vertical-cues-hls.html
or
https://jernoble.github.io/samples/bin/WebVTT/hls-styling.html
.
gglendinning
Comment 4
2025-03-04 16:12:38 PST
Hi, apologies, I did not notice the response to this. I have been able to replicate the issue which only exists from iOS 18.2+. The exact cause of the issue was introduced in this commit:
https://github.com/WebKit/WebKit/commit/bed0c2a8cb8ae071886d43295d004058a17188a0#diff-0d1c50cc9605a92ad58164815993adbe319d5bb889654c79aceb0a4c1f69a165
Reverting the change (by overriding with !important) resolves the issue, as defined here:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/Modules/modern-media-controls/controls/text-tracks.css#L68
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/Modules/modern-media-controls/controls/text-tracks.css#L93
Changing the "cqmin" back to "cqh" resolves the issue for 16:9 video. I expect the change _probably_ fixes TikTok-style 2:1 aspect videos but in doing so, makes subtitles unreadable on iOS 18.2+ for 16:9 and similar "letterbox" aspect ratios. Unfortunately I cannot provide a full working test due to NDA's and DRM.
gglendinning
Comment 5
2025-03-04 16:13:10 PST
Reopening with details.
Jer Noble
Comment 6
2025-03-05 15:22:40 PST
> Changing the "cqmin" back to "cqh" resolves the issue for 16:9 video. I expect the change _probably_ fixes TikTok-style 2:1 aspect videos but in doing so, makes subtitles unreadable on iOS 18.2+ for 16:9 and similar "letterbox" aspect ratios.
I'm not sure I understand, as 16:9 usually refers to a "landscape" aspect ratio where the width is greater than the height, in which case `cqmin` would be the same as `cqh`. And if you mean a "portrait" aspect ratio of 9:16, then that should result in larger font sizes than a "TikTok-style 1:2" aspect ratio. In neither case are the subtitles "unreadable". You can see the difference in rendering with this example:
https://jernoble.github.io/samples/bin/WebVTT/resize-aspect.html
Regardless, the default font size is just a default, and as you mention, it can be overridden.
gglendinning
Comment 7
2025-03-06 06:41:13 PST
Created
attachment 474474
[details]
Before overriding CSS
gglendinning
Comment 8
2025-03-06 06:41:33 PST
Created
attachment 474475
[details]
After overriding CSS
gglendinning
Comment 9
2025-03-06 06:43:49 PST
Due to DRM, the video itself does not display, but this is iOS 18.3 in fullscreen mode. I am unable to use the link you provided to verify the behaviour as it is only apparent in a video in fullscreen mode. Your link contains no videos, therefore impossible to enter fullscreen to verify. The screenshots are from a 16:9 video encoded at 1920*1080 in fullscreen mode.
gglendinning
Comment 10
2025-03-06 06:44:49 PST
(In reply to gglendinning from
comment #9
)
> Due to DRM, the video itself does not display, but this is iOS 18.3 in > fullscreen mode. > > I am unable to use the link you provided to verify the behaviour as it is > only apparent in a video in fullscreen mode. Your link contains no videos, > therefore impossible to enter fullscreen to verify. > > The screenshots are from a 16:9 video encoded at 1920*1080 in fullscreen > mode.
I should have also noted, the text tracks render at the same size in both portrait and landscape mode; the attachments are in portrait.
Jer Noble
Comment 11
2025-03-06 15:18:53 PST
Created
attachment 474477
[details]
BipBop-subtitle-fullscreen Okay, so if I understand this correctly, the underlying issue is that when a wide-landscape-aspect-ratio video (e.g., 16:9) is displayed in a tall-portrait-aspect-ratio viewport (e.g., an iPhone in portrait fullscreen mode), displaying cues at 5% of the height of the video frame (in your example, the video area will be 678px tall and 1206px wide) will result in cues whose height is 33px, or about 1.2% of the height of the device. However, that behavior appears to match the behavior of native subtitle rendering on iOS. Subtitles are intended to be sized relative to the video content, not the letterboxed fullscreen area. The video area is just small; the same problem exists in PiP regardless of orientation because it too is small. Attaching an example which just uses native AVKit (i.e., not web content) to display captions in fullscreen. The captions are approximately the same size as the screenshots you posted.
Dana Estra
Comment 12
2025-04-01 10:48:24 PDT
*** This bug has been marked as a duplicate of
bug 290576
***
Dana Estra
Comment 13
2025-04-01 10:51:50 PDT
Thank you for your report! I accidentally opened a new issue while posting a fix for this bug- I have marked this bug as a duplicate of the new one where the fix is.
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