Last item in overlay pop-up gets cut off

[rusty-snake]

Previous: Helium314#723

How to Reproduce

• Have a small screen high, e.g. use split-screen or landscape
• Open overlay pop-up
• Scroll to end
• See buildings overlay is (partial) cut of

SCEE: Screen high does not matter because custom overlay feature

Expected Behavior

Versions affected

• SC 60.1
• Adnroid 15 QPR 1

[mic140]

In Android 13, in landscape orientation, the list of overlays scrolls and no cropping is observed.

[mnalis]

Also seems to work fine in SC 60.1 on my Samsung Galaxy S23+ in Landscape mode (Android 14):

small_Screen_Recording_20250113_211452_StreetComplete.mp4

I'll try to test with few older testing phones I have soon.

Smells like possible insets issue; @rusty-snake do you know (or could you test) if you have the same issue in SC v59.3 or earlier?

(changes about Compose/insets started with 60.0-alpha1, e.g. #6030)

[mnalis]

I'll try to test with few older testing phones I have soon.

Can't reproduce the problem with older phones, so perhaps it is android 15+ issue (or just chance)? But I do see inset handling differences though, so that may be the cause of the bug too:

• with Samsung Galaxy S23+ (Android 14) and Redmi Note 6 Pro (Android 11) the copyright lines are covered
  

• On Huawei P30 Pro (Android 10) and Redmi Note 3 Pro (Android 6.0.1) the Overlay selection window does not cover copyright lines at the bottom, but
  

more screenshots (click to expand...)


[rusty-snake]

Smells like possible insets issue; @rusty-snake do you know (or could you test) if you have the same issue in SC v59.3 or earlier?

v59.3 and v60.0 work fine.

[westnordost]

Reproducible on an Android 15 emulator in landscape mode.

[westnordost]

Hmm, I investigated this a bit:

I am assuming that the window insets are not applied to the dropdown because the DropDownMenu is part of the overall layout (as it should be) and according to the window insets documentation, the window insets are already consumed by the parent layout, i.e. the layout that contains all those buttons on the map.

For this reason, I can understand that adding a .safeDrawingPadding() (or .windowInsetsPadding(WindowInsets.safeDrawing)) as a modifier to the DropDownMenu doesn't do anything (tried it).

So, if I - for testing - just add a general padding of 40.dp on the top and bottom:

• onto the DropDownMenu, it just adds the padding within dropdown menu, not around it. Not what we want
• onto a Box that wraps the DropDownMenu, it has no effect whatsoever

So it looks like that I cannot even influence the padding around the dropdown menu.

Arguably, the dropdown menu should already be constrained by the window insets padding of its parent layout, but at least on Androi 15, it isn't -

It is only reproducible on Android 15, not below. This is somewhat worrying (i.e. probably a bug in Android and/or Compose), because the behavior should be the same when edge-to-edge is enabled for all platforms.

I am contemplating to report this as a bug, but I'll probably need to build a minimum app with which this can be reproduced. Also, I am not sure where to report it.

[mnalis]

There have been a lot of inset-related changes to Android 15, it seems:
https://developer.android.com/about/versions/15/behavior-changes-15#window-insets

I wonder if skipping calling enableEdgeToEdge() works around the problem? (as in #6030 (comment)). Obviously not to be used as an actual workaround (as Android 15 will be around for a while), but as a data point which part of the inset handling is affected.

[westnordost]

ofc I already call enableEdgeToEdge

[riQQ]

mnalis is proposing to check if the bug also occurs when not calling enableEdgeToEdge.

[westnordost]

I created a minimal Android Studio project with which one can reproduce this issue and posted a bug report here:

https://issuetracker.google.com/issues/391393405

Currently, I don't see a possibility to work around this and the priority to find a workaround is relatively low (as the last item in the dropdown is clickable nevertheless), so I am inclined to close this as an upstream issue.

[matkoniecz]

Makes sense, unless someone will find reasonable workaround.

[mnalis]

mnalis is proposing to check if the bug also occurs when not calling enableEdgeToEdge.

To answer my own question: Interestingly, bug seems to be there regardless whether enableEdgeToEdge is called or not:

Regular StreetComplete 60.1 (i.e. with enableEdgeToEdge ):

modified StreetComplete (i.e. without enableEdgeToEdge):

Device is Xiaomi Redmi Note 13 4G (Android 15)