Safe areas are not handled correctly on iPhone X #3066

borisyankov · 2018-10-20T17:07:14Z

We are currently handling, but not 100% correctly, the 'screen border offsets' known as 'safe areas' on iOS. One such bug: iPhone X with a popped keyboard has some extra space below the compose box

Fixes zulip#3066 Previous approach almost worked correctly, but there was one case it didn't - when the keyboard did pop on an iPhone, the bottom space was sill there, though it shouldn't, as the keyboard is located over the `Home Indicator`.

gnprice · 2018-12-03T20:27:02Z

Blocked on the React Navigation v2 upgrade #2702 .

Fixes zulip#3066 Previous approach almost worked correctly, but there was one case it didn't - when the keyboard did pop on an iPhone, the bottom space was sill there, though it shouldn't, as the keyboard is located over the `Home Indicator`.

gnprice · 2019-06-04T22:16:44Z

@jackrzhang provided (on #3389) some handy screenshots that very clearly demonstrate one of the symptoms of this issue:

On any iPhone X model, the upper edge of the screen covers part of the application UI in landscape orientation:

[...]

I don't have a physical iPhone X device to use for testing, so it's also possible that this reproduces only on a simulator.

gnprice · 2019-06-04T22:20:44Z

I think #3370 is probably also a symptom, indirectly:

[From a video by @armaanahluwalia to demonstrate a different issue:]

A blank white band between the compose box and the keyboard.

Didn't repro for me on Android, and @jackrzhang reported it repro'd for him on a simulated iPhone XR but not on an iPhone 7. So that's consistent with it happening only on iOS devices that have a display cutout.

I suspect it's caused by the logic we have for attempting to avoid the cutout, i.e. by a bug in that logic.

gnprice · 2019-06-06T21:49:22Z

Additional info from the dupe issue #3064 (filed just before this one), quoting @borisyankov:

When iPhone X was released, new functionality to iOS was added to indicate safe area - to help with apps handling optional notches, rounded corners or the ...

A good article explaining all this here:
https://medium.com/rosberryapps/ios-safe-area-ca10e919526f

We started using a component react-native-safe-area to handle this.

It isn't working perfectly and we need to fix it.
Testing on iOS X or Simulator with it makes few layout issues obvious.

Better yet, use the now built-in component:
https://facebook.github.io/react-native/docs/safeareaview

Fixes zulip#3066 Previous approach almost worked correctly, but there was one case it didn't - when the keyboard did pop on an iPhone, the bottom space was sill there, though it shouldn't, as the keyboard is located over the `Home Indicator`.

chrisbobbe · 2020-12-31T03:39:52Z

#4315 would have us using a more maintained thing for getting the safe-area insets.

chrisbobbe · 2021-01-07T16:36:59Z

OK, now that #4315 is merged, we're using react-native-safe-area-context instead of react-native-safe-area to provide the safe-area insets. We've stopped storing the values in Redux; the new module uses React Context.

As discussed around here, the new module is not without flaws, though.

It offers a useSafeAreaInsets hook and a withSafeAreaInsets HOC, which will provide the insets in a live-updating way, so that the values are even correct when switching between screen orientations. There are some hiccups in that live-updating, though; see #4315 (comment) for some observations.

The preferred solution to try will be to try to use SafeAreaView, a React component provided by the module, instead of useSafeAreaInsets/withSafeAreaInsets. It's specifically recommended because it doesn't have any flickers when changing screen orientations.

If that doesn't work and we have to use useSafeAreaInsets/withSafeAreaInsets, we'll need to do some debugging about those flickers.

chrisbobbe · 2021-04-09T17:58:45Z

I plan to make a focused PR to fix this issue after #4468 is in.

Each of these UI elements is a row that has meaningful content that we need to keep within the safe areas, but the rest of the row (its distinct background color, its touchable area, etc.) is meant to extend through the insets to the extreme left and right of the screen. See example screenshots at zulip#4683 (comment). So, make that happen. We do so by giving the rows left and right padding. This is easy and makes the row elements' styles pretty intuitive, but it does mean we'll have to take care, in the next few commits, not to add any padding to the elements that contain the rows -- we don't want to double up the padding by mistake. (This requirement ends up being kind of annoying on screens that have a mix of these kinds of rows and regular elements. Possibly there's a better design pattern we haven't yet considered.) Related: zulip#3066

This isn't ideal; it just puts the whole message list in a box that's contained within the safe area. The message list was designed to span the entire width of the screen, and some things look pretty bad when the insets are nonzero [1]: the timestamp pills, for one example, look like they get cut off artificially instead of being tucked away somewhere offscreen. Things like that would best be solved with a more in-depth design discussion. A more complete solution might start with the "env" CSS function [2], or, less optimally, a new WebView inbound event to be fired whenever the insets change. At least this solution lets things be visible and interactable that weren't before. I think this completes zulip#3066 (modulo this message-list issues discussed here), which is our current audit for safe-area handling. [1] So far, I think this is just landscape mode on newer iOS devices, but I might be missing something. [2] https://webkit.org/blog/7929/designing-websites-for-iphone-x/ Fixes: zulip#3066

Each of these UI elements is a row that has meaningful content that we need to keep within the safe areas, but the rest of the row (its distinct background color, its touchable area, etc.) is meant to extend through the insets to the extreme left and right of the screen. See example screenshots at zulip#4683 (comment). So, make that happen. We do so by giving the rows left and right padding. This is easy and makes the row elements' styles pretty intuitive, but it does mean we'll have to take care, in the next few commits, not to add any padding to the elements that contain the rows -- we don't want to double up the padding by mistake. (This requirement ends up being kind of annoying on screens that have a mix of these kinds of rows and regular elements. But this is unfortunately the workable design we've found; see our architecture doc on handling safe areas.) Related: zulip#3066

This isn't ideal; it just puts the whole message list in a box that's contained within the safe area. The message list was designed to span the entire width of the screen, and some things look pretty bad when the insets are nonzero [1]: the timestamp pills, for one example, look like they get cut off artificially instead of being tucked away somewhere offscreen. Things like that would best be solved with a more in-depth design discussion. A more complete solution might start with the "env" CSS function [2], or, less optimally, a new WebView inbound event to be fired whenever the insets change. At least this solution lets things be visible and interactable that weren't before. I think this completes zulip#3066 (modulo this message-list issue discussed here), which is our current audit for safe-area handling. [1] So far, I think this is just landscape mode on newer iOS devices, but I might be missing something. [2] https://webkit.org/blog/7929/designing-websites-for-iphone-x/ Fixes: zulip#3066

Each of these UI elements is a row that has meaningful content that we need to keep within the safe areas, but the rest of the row (its distinct background color, its touchable area, etc.) is meant to extend through the insets to the extreme left and right of the screen. See example screenshots at zulip#4683 (comment). So, make that happen. We do so by giving the rows left and right padding. This is easy and makes the row elements' styles pretty intuitive, but it does mean we'll have to take care, in the next few commits, not to add any padding to the elements that contain the rows -- we don't want to double up the padding by mistake. (This requirement ends up being kind of annoying on screens that have a mix of these kinds of rows and regular elements. But this is unfortunately the workable design we've found; see our architecture doc on handling safe areas.) Related: zulip#3066

This isn't ideal; it just puts the whole message list in a box that's contained within the safe area. The message list was designed to span the entire width of the screen, and some things look pretty bad when the insets are nonzero [1]: the timestamp pills, for one example, look like they get cut off artificially instead of being tucked away somewhere offscreen. Things like that would best be solved with a more in-depth design discussion. A more complete solution might start with the "env" CSS function [2], or, less optimally, a new WebView inbound event to be fired whenever the insets change. At least this solution lets things be visible and interactable that weren't before. I think this completes zulip#3066 (modulo this message-list issue discussed here), which is our current audit for safe-area handling. [1] So far, I think this is just landscape mode on newer iOS devices, but I might be missing something. [2] https://webkit.org/blog/7929/designing-websites-for-iphone-x/ Fixes: zulip#3066

Each of these UI elements is a row that has meaningful content that we need to keep within the safe areas, but the rest of the row (its distinct background color, its touchable area, etc.) is meant to extend through the insets to the extreme left and right of the screen. See example screenshots at zulip#4683 (comment). So, make that happen. We do so by giving the rows left and right padding. This is easy and makes the row elements' styles pretty intuitive, but it does mean we'll have to take care, in the next few commits, not to add any padding to the elements that contain the rows -- we don't want to double up the padding by mistake. (This requirement ends up being kind of annoying on screens that have a mix of these kinds of rows and regular elements. But this is unfortunately the workable design we've found; see our architecture doc on handling safe areas.) Related: zulip#3066

This isn't ideal; it just puts the whole message list in a box that's contained within the safe area. The message list was designed to span the entire width of the screen, and some things look pretty bad when the insets are nonzero [1]: the timestamp pills, for one example, look like they get cut off artificially instead of being tucked away somewhere offscreen. Things like that would best be solved with a more in-depth design discussion. A more complete solution might start with the "env" CSS function [2], or, less optimally, a new WebView inbound event to be fired whenever the insets change. At least this solution lets things be visible and interactable that weren't before. I think this completes zulip#3066 (modulo this message-list issue discussed here), which is our current audit for safe-area handling. [1] So far, I think this is just landscape mode on newer iOS devices, but I might be missing something. [2] https://webkit.org/blog/7929/designing-websites-for-iphone-x/ Fixes: zulip#3066

borisyankov self-assigned this Oct 22, 2018

borisyankov added bug a-iOS labels Oct 22, 2018

borisyankov changed the title ~~Safe areas are not handled correctly on iPhone X and Androids with notches~~ Safe areas are not handled correctly on iPhone X Oct 22, 2018

borisyankov added the P1 high-priority label Nov 28, 2018

gnprice added the blocked on other work To come back to after another related PR, or some other task. label Dec 3, 2018

gnprice mentioned this issue Dec 3, 2018

Upgrade to React Navigation v2 #2702

Closed

This was referenced Jun 4, 2019

Use 'SafeAreaView' through the app #3067

Closed

lightbox: Fix SafeAreaInsets padding is not applied. #3292

Closed

The upper edge of an iPhone X screen covers part of the UI in landscape orientation. #3389

Closed

gnprice mentioned this issue Jun 4, 2019

Blank strip between compose box and keyboard #3370

Closed

gnprice added the a-layout label Jun 4, 2019

gnprice mentioned this issue Jun 6, 2019

Fix notch handling, with SafeAreaView #3064

Closed

gnprice mentioned this issue Jun 14, 2019

Android: sometimes screen does not stretch completely #3068

Open

gnprice unassigned borisyankov Jun 17, 2019

gnprice mentioned this issue Jul 26, 2019

Upgrade react-navigation to v2 #3573

Closed

gnprice removed the blocked on other work To come back to after another related PR, or some other task. label Aug 12, 2019

gnprice mentioned this issue Nov 14, 2020

React Navigation v5 upgrade (part 1) #4300

Merged

chrisbobbe mentioned this issue Nov 16, 2020

lightbox: Fix lack of access to close button on some iOS devices. #4268

Closed

This was referenced Dec 30, 2020

Avatars don't work on iOS 14, except in message list #4365

Closed

No margin for main bottom nav on iPhone 12 #4369

Closed

chrisbobbe mentioned this issue Jan 7, 2021

Stop storing safeAreaInsets in Redux; use react-native-safe-area-context instead. #4315

Closed

chrisbobbe mentioned this issue Jan 22, 2021

Clean up navigation logic (1/x). #4428

Merged

gnprice assigned gnprice and chrisbobbe and unassigned gnprice Jan 26, 2021

gnprice mentioned this issue Jan 27, 2021

Clean up navigation logic (2/x). #4440

Merged

chrisbobbe mentioned this issue Jan 29, 2021

Clean up navigation logic (3/x). #4443

Merged

chrisbobbe mentioned this issue Apr 9, 2021

Clean up navigation logic (4/x): Tidy up our use of ZulipStatusBar a bit more. #4468

Merged

chrisbobbe mentioned this issue Apr 20, 2021

More prep work for handling safe areas. #4683

Merged

chrisbobbe mentioned this issue May 14, 2021

ServerCompatNotice: Add, to nag users connected to servers <2.0.0. #4750

Merged

chrisbobbe linked a pull request Jul 12, 2021 that will close this issue

Handle safe areas (mostly). #4893

Draft

This was referenced Jul 13, 2021

Put lightbox header/footer text and buttons in the safe area. #4442

Merged

Unable to close image preview dialog on iphone #4267

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Safe areas are not handled correctly on iPhone X #3066

Safe areas are not handled correctly on iPhone X #3066

borisyankov commented Oct 20, 2018 •

edited

Loading

gnprice commented Dec 3, 2018

gnprice commented Jun 4, 2019

gnprice commented Jun 4, 2019

gnprice commented Jun 6, 2019

chrisbobbe commented Dec 31, 2020

chrisbobbe commented Jan 7, 2021 •

edited

Loading

chrisbobbe commented Apr 9, 2021

Safe areas are not handled correctly on iPhone X #3066

Safe areas are not handled correctly on iPhone X #3066

Comments

borisyankov commented Oct 20, 2018 • edited Loading

gnprice commented Dec 3, 2018

gnprice commented Jun 4, 2019

gnprice commented Jun 4, 2019

gnprice commented Jun 6, 2019

chrisbobbe commented Dec 31, 2020

chrisbobbe commented Jan 7, 2021 • edited Loading

chrisbobbe commented Apr 9, 2021

borisyankov commented Oct 20, 2018 •

edited

Loading

chrisbobbe commented Jan 7, 2021 •

edited

Loading