WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
300232
Incorrect safe area values with scrollview inset and obscured inset (in clients other than Safari)
https://bugs.webkit.org/show_bug.cgi?id=300232
Summary
Incorrect safe area values with scrollview inset and obscured inset (in clien...
fedegermi
Reported
2025-10-06 05:53:17 PDT
Created
attachment 476976
[details]
Example project When both the scrollview inset and the obscured inset are set, the reported safe area values are incorrect. Test website:
https://adangla.github.io/check_css.html
(source:
https://github.com/adangla/adangla.github.io/blob/main/check_css.html
) You can find an example app in the attachment (safe-area-obscured-inset-ios26.zip). Expected behavior: CSS variable returns 0 when the top toolbar is larger than the safe area. Actual Behavior: Instead of returning 0, the safe area CSS value (or equivalent) returns 62, which is the standard top safe area value. This indicates that the system is not correctly accounting for the combined occlusion from both the scrollview inset and the obscured inset, leading to an inaccurate representation of the truly safe usable space.
Attachments
Example project
(38.82 KB, application/zip)
2025-10-06 05:53 PDT
,
fedegermi
no flags
Details
Example on Safari
(661.62 KB, image/png)
2025-10-06 05:56 PDT
,
fedegermi
no flags
Details
Example of broken behavior
(629.46 KB, image/png)
2025-10-06 05:58 PDT
,
fedegermi
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
fedegermi
Comment 1
2025-10-06 05:56:44 PDT
Created
attachment 476977
[details]
Example on Safari Note that in this case the behavior is correct, the top safe area is equal to 0.
fedegermi
Comment 2
2025-10-06 05:58:44 PDT
Created
attachment 476978
[details]
Example of broken behavior Note that in this base the top value is not 0 (like in Safari) but it's 62. It can be reproduced from the attached test project.
fedegermi
Comment 3
2025-10-06 05:59:21 PDT
Note that we were not able to reproduce this on Safari because the top toolbar is bigger than the safe area. We can only reproduce this issue when this is not true. Please let us know if you need additional information.
Radar WebKit Bug Importer
Comment 4
2025-10-13 05:54:11 PDT
<
rdar://problem/162521096
>
Wenson Hsieh
Comment 5
2025-10-13 13:12:16 PDT
Thanks for the report! I can reproduce on 26.1. Debugging into this a bit, it seems this only works in Safari because Safari uses `-[WKWebView _setUnobscuredSafeAreaInsets:]` to override unobscured safe area insets, which sets the `_haveSetUnobscuredSafeAreaInsets` flag; the value is then returned here: ``` - (UIEdgeInsets)_computedUnobscuredSafeAreaInset { if (_haveSetUnobscuredSafeAreaInsets) return _unobscuredSafeAreaInsets; // < - - - - if (!self._safeAreaShouldAffectObscuredInsets) { auto safeAreaInsets = self.safeAreaInsets; #if PLATFORM(WATCHOS) safeAreaInsets = UIEdgeInsetsAdd(safeAreaInsets, self._contentInsetsFromSystemMinimumLayoutMargins, self._effectiveObscuredInsetEdgesAffectedBySafeArea); #endif return safeAreaInsets; } return UIEdgeInsetsZero; } ``` We probably need to adjust the code in the `!self._safeAreaShouldAffectObscuredInsets` case below the `_haveSetUnobscuredSafeAreaInsets` early return…
Wenson Hsieh
Comment 6
2025-10-14 20:09:47 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/52362
EWS
Comment 7
2025-10-14 23:27:27 PDT
Committed
301534@main
(af80de949632): <
https://commits.webkit.org/301534@main
> Reviewed commits have been landed. Closing PR #52362 and removing active labels.
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