RESOLVED FIXED300232
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
Example on Safari (661.62 KB, image/png)
2025-10-06 05:56 PDT, fedegermi
no flags
Example of broken behavior (629.46 KB, image/png)
2025-10-06 05:58 PDT, fedegermi
no flags
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
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
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.