Full height Modal Bottom Sheet best practices clarification and doc update request [321877275]

Assigned

Bug

Status Update

No update yet.

Description

da...@gmail.com

created issue #1

Jan 23, 2024 05:27PM

Reviewing the modal bottom sheet spec here I am not clear on exactly what happens in different cases where the modal bottom sheet is full height

https://m3.material.io/components/bottom-sheets/guidelines#22deb8a2-3513-4a2e-aa47-c64875e15e12

It states:

They can be dismissed by:

Using a close affordance within the bottom sheet’s top app bar, if available

Display a close affordance in a full-screen modal bottom sheet.

The above is the link of what to do in that situation but I think there is more clarification needed and maybe there is multiple ways Material recommends to do this?

Is this saying there should be a collapse icon in the app bar as I do not see it. Should we include an x icon in the content of the bottomsheet / replace the drag handle with it?

The full expanded modal bottomsheet on the material sample app maintains a drag handle and does not merge into the top bar (see screenshot)

Screenshot_20240123-112546.png

108 KB

View

Download

Comments

ma...@google.com <ma...@google.com> Jan 23, 2024 09:11PM

Reassigned to ma...@google.com.

se...@google.com <se...@google.com> #2May 15, 2024 07:29PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

da...@gmail.com <da...@gmail.com> #3May 16, 2024 12:33AM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

da...@well.co <da...@well.co> #4May 21, 2024 02:17PM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

se...@google.com <se...@google.com> #5Jul 24, 2024 06:38PM

Reassigned to lu...@google.com.

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

ap...@google.com <ap...@google.com> #6Oct 2, 2024 07:56PM

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

Issue 321877275