IssueTracker

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.

Compose 1.7 has a bug that causes ANR when the focus is on EditText. https://issuetracker.google.com/issues/369354336

Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus(). https://issuetracker.google.com/issues/374031296

Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.

In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.

Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <halilibo@google.com>
Link:      https://android-review.googlesource.com/3317256

Fix POBox keyboard issue

Fix POBox keyboard issue 
 
Fix: 373743376 
Fix: 329209241 
Test: NullableInputConnectionWrapperTest 
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1

Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.

Yes, this fix is planned to be included in a future 1.7.x release.

Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.

Perfect.

Just quickly tested the

.fillMaxSize()
.wrapContentHeight()

And it seems to behave correctly for the dialog scrim so works as a solution, may worth a note somewhere as cheating with usePlatformDefaultWidth = false was often found as solution in a few posts over Internet.

A quick "mostly" related question to the dialog scrim, many users requested an option to hide the status bar in my app to be in full immersive mode, but there's no way to do that with dialogs right now. Is this something that can be requested? I have a fork of M3 BottomSheet to handle that, but handling a fork of the low level dialog requires a full copy and rewrite of everything that depends on it.

Have you tried using the DialogWindowProvider?:

fun findDialogWindowProviderInParent(view: View): DialogWindowProvider? {
    if (view is DialogWindowProvider) {
        return view
    }
    val parent = view.parent ?: return null
    if (parent is View) {
        return findDialogWindowProviderInParent(parent)
    }
    return null
}

@Composable
MyDialogContent() {
    val dialogWindowProvider = findDialogWindowProviderInParent(LocalView.current)
    dialogWindowProvider?.window?.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
    ...
}

Not at all I always failed at finding the proper window, this works perfectly thanks a lot.

                        val dialogWindowProvider = findDialogWindowProviderInParent(LocalView.current)
                        val window = dialogWindowProvider?.window
                        if (window != null) {
                            WindowCompat.getInsetsController(window, window.decorView).apply {
                                hide(WindowInsetsCompat.Type.statusBars())
                                systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
                            }
                        }

Returning to the 2nd issue about the lag and your solution.

Using a .fillMaxSize() breaks the second .fillMaxWidth(0.8f). In my case since only the height change I can use a .fillMaxHeight() but I do not really understand what is happening. See attached screenshots.

I can just return to usePlatformDefaultWidth = true since your workaround fixes the lag and then it behave as expected.

So just reporting in case there's something else about measurement that changes and was not expected.

Ok and now the memories slowly comes back :(

1. usePlatformDefaultWidth = true and dialog resizing issues.

Use the following dialog content with the content from #4 and usePlatformDefaultWidth = true

Surface(
                            modifier = modifier
                                .safeContentPadding()
                                .fillMaxWidth(0.8f),
                            shape = shape,
                            color = backgroundColor,
                            contentColor = contentColor,
                        ) {
                            dialogNavigator.SaveableState("currentDialog") {
                                dialogContent(dialogNavigator)
                            }
                        }

It gives the result plaformnoanimate.png attached.

With

 Surface(
                            modifier = modifier
                                .safeContentPadding()
                                .animateContentSize(),
                            shape = shape,
                            color = backgroundColor,
                            contentColor = contentColor,
                        ) {
                            dialogNavigator.SaveableState("currentDialog") {
                                dialogContent(dialogNavigator)
                            }
                        }

It gives the result platformanimate.png

Both are wrong as the dialog does not properly resized on content change, strangely I can't find the issue on the tracker but I'm pretty sure there was one opened about that since ages and the reasons we had to migrate to use usePlatformDefaultWidth = false. Those hacks are so old on my side that I have an hard time remembering all the details :(

2. .fillMaxSize() breaks the dismissOnClickOutside

As per this item title, adding the fillMaxSize prevent click outside to dismiss the dialog so it not really a proper workaround.

All those tests are made with alpha 4 that contains the CL.

Adding a final note if anyone reads and needs a solution.

                        Box(
                            modifier = Modifier
                                .safeDrawingPadding()
                                .fillMaxSize()
                                .padding(horizontal = 32.dp)
                                .clickable {
                                    if (dialogState.canDismiss.value) {
                                        dialogNavigator.hide()
                                    }
                                }
                        ) {
                            Surface(
                                modifier = modifier
                                    .align(Alignment.Center)
                                    .sizeIn(maxWidth = 640.dp)
                                    .clickable(enabled = false) {}
                                    .animateContentSize(),
                                shape = shape,
                                color = backgroundColor,
                                contentColor = contentColor,
                            ) {
                                dialogNavigator.SaveableState("currentDialog") {
                                    dialogContent(dialogNavigator)
                                }
                            }
                        }

Beware that this still only works properly with usePlatformDefaultWidth = false

See resulting video "works"

With usePlatformDefaultWidth = true this will give the result "notwork" where the dialog width animate (while it should not, the actual width never changes) but the content does not seems to react so the title is on 2 lines. (The title is a simple Text() present on first display, not a later change)

I think I covered most of the issues with dialogs here. Some very old that where workarounded via usePlatformDefaultWidth=false and some that are now also present in usePlatformDefaultWidth=false due to window resizing (But working better than the other case)

Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <mount@google.com>
Link:      https://android-review.googlesource.com/3312260

Set default Gravity for Dialogs to CENTER

Set default Gravity for Dialogs to CENTER

Fixes: 373093006

On some devices, the default gravity for dialogs is not CENTER.
This changes the default gravity for Compose dialogs to CENTER.

Test: new test, manual testing on broken device
Change-Id: Ia2ec9f6edc2705cb8a13201d5e05a859a6bb9571

Can we discuss the other issues too?

I guess that's a no and I documented all the issues for nothing.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.ui:ui:1.8.0-alpha05
• androidx.compose.ui:ui-android:1.8.0-alpha05
• androidx.compose.ui:ui-jvmstubs:1.8.0-alpha05
• androidx.compose.ui:ui-linuxx64stubs:1.8.0-alpha05