Unexpected notch behavior

[mehmetf]

Here's a sample app: https://gist.github.com/mehmetf/0bae55d83574e378705174bd9fec012b

When SafeArea is not used, in landscape:

• there is padding added in at the start and end of the ListViews
• the FAB is also offset
• the padding is larger than the actual notch (see screenshots 1, 2, 3, and 4).

When SafeArea is used, in landscape:

• there is padding added on both ends
• the padding is larger than the actual notch (see screenshots 5 and 6)

iPhone X screenshots:

1. Portrait, without SafeArea, ListViews scrolled to start
   

2. Portrait, without SafeArea, ListViews scrolled to end
   

3. Landscape, without SafeArea, ListViews scrolled to start
   

4. Landscape, without SafeArea, ListViews scrolled to end
   

5. Portrait, with SafeArea
   

6. Landscape, with SafeArea
   

iPhone X/without SafeArea/Portrait: padding=EdgeInsets(0.0, 44.0, 0.0, 34.0) : viewInsets=EdgeInsets.zero
iPhone X/without SafeArea/Landscape: padding=EdgeInsets(44.0, 0.0, 44.0, 21.0) : viewInsets=EdgeInsets.zero
iPhone X/with SafeArea/Portrait: padding=EdgeInsets(0.0, 44.0, 0.0, 34.0) : viewInsets=EdgeInsets.zero
iPhone X/with SafeArea/Landscape: padding=EdgeInsets(44.0, 0.0, 44.0, 21.0) : viewInsets=EdgeInsets.zero

[mehmetf]

@HansMuller How many of these behaviors are expected and what is their rationale? I am posting this on behalf of a team in Google. If you want to look at the internal entry (which has additional use cases), please ping me.

[HansMuller]

As far as I can tell SafeArea and ListView are working as intended given the window padding values reported by the engine. I tested the material/framework aspects of this issue with a version of the original app: https://gist.github.com/HansMuller/ccec021e75ca9adb1dbaae83efedfecd

I agree that the portrait MediaQuery value looks wrong, not clear why there's bottom padding. The landscape simulator screenshot doesn't look right either: what's the microphone doing at the bottom (screenshot 6)?

[mehmetf]

Thanks Hans. Who should this be routed to? I am not sure who handles MediaQuery in the engine?

[HansMuller]

cc @cbracken It looks like there's a problem here, maybe with the iPhoneX emulator, maybe with the way the engine is computing the window's padding.

[talbog]

Hi All,
Thanks to Mehmet for posting this for me. I am the engineer that originally reported this problem, and want to clarify that this behaviour was observed on both the emulator, and on a physical device.

Another note, unlike what Hans reported, I don't think that the bottom padding is wrong, it is there for the bottom button (which looks like a speaker cutout). The landscape MediaQuery padding is what looks wrong to me as it has padding on both the left and right when the notch is only on one end (not both).

[HansMuller]

@talbog - The ListView in https://gist.github.com/HansMuller/ccec021e75ca9adb1dbaae83efedfecd pads its content on the left and right because the Flutter engine (ui.window) reports 44.0 of padding and both the left and right.

[talbog]

@HansMuller - That's interesting, on the project I'm working on there are two ListViews stacked vertically much like what I put together for the example shown in this issue, but only one of the ListViews was getting padded.

[cbracken]

Unless I'm misunderstanding this request, this looks like Flutter's padding/insets are working as intended. On iPhone X class devices in horizontal layout mode, the expectation is that the safe area insets are symmetric on either side of the display. The bottom padding is also expected so as to avoid interations in the area taken up by the home screen indicator bar.

Apple used to have a very nice introductory page (Wayback Machine link) that covers designing for the iPhone X, but it appears to have been replaced by more generic content in the Layout Guides and Safe Area section of the Adaptivity and Layout chapter of Apple's Human Interface Guidelines. The UIKit: Apps for Every Size and Shape presentation from WWDC 2018 may be useful as well.

Implementation-wise, the engine currently just passes through the safe area insets reported by iOS.

If you do want to override the default behaviour, you should be able to do so either by using the SafeArea boolean parameters or through MediaQuery.removePadding.

Hope that helps -- please let me know if I've misunderstood the issue here.

[HansMuller]

The designing for the iPhone X introductory page (Wayback Machine link) that @cbracken mentioned includes an illustration that highlights the portrait and landscape safe areas:

Hopefully it's clear that (for whatever reason), in landscape mode the horizontal safe area insets are symmetrical, larger than the notch on the left, and exist even though there's no notch on the right.

[talbog]

Hi Chris,
Thanks for all the information, and digging up all those pages.

That seems like an odd choice on Apple's part as it's basically throwing away perfectly usable screen real estate, but I'm guessing it probably has to do with the fact that in landscape there is padding at the bottom but not at the top, and as a result the top could be clipped by the rounded corner.

When in landscape is there a way to know on which side the notch actually is?

[cbracken]

As far as I'm aware, Apple doesn't provide a public API specifically for looking up which side the notch is on, but if you were willing to make assumptions about the set of known devices, DeviceOrientation would basically provide the info you need.

[talbog]

Great, thanks Chris and Hans for all your help on this!

I think it's safe to mark this as "working as intended".