Android Entry control is covered by keyboard or the wrong Entry control is moved up to be visible.

[philipag]

Description

In XF, the Entry control lost focus when the Android soft keyboard was closed with the back button. In MAUI this is no longer the case, which is a bug.

Steps to Reproduce

1. Compile and run the repro sample under Android 11.
2. click on the text "click me" so that the soft keyboard opens and "click me" has a flashing cursor.
3. click the "back" button to close the keyboard.
4. Note that "click me" still has a flashing cursor. Also, noteFilter_Unfocused is not called. If I press back again in order to place the entire app in the background, then noteFilter_Unfocused is called.

When closing the soft keyboard, noteFilter_Unfocused should be called AND the Entry control should no longer display the flashing cursor. This worked properly in XF so this is a regression in MAUI.

layoutbug9.zip

Version with bug

Release Candidate 2 (current)

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Android 11

Did you find any workaround?

No

Relevant log output

No response

[XamlTest]

Verified this issue with Visual Studio Enterprise 17.3.0 Preview 1.0 [32427.455.main]. Repro on Android 11 with above project.

[danielftz]

ETA on this issue?

[philipag]

Yes please. Cannot release a production app with this regression unless there is a good workaround.

[ssalvadoPT]

Still no advance on this? It's not just the back action, tapping somewhere else on the screen should dismiss the keyboard (unless tapping another entry, ofc). It worked in XF. Please fix this on MAUI.

[philipag]

@jsuarezruiz Your pull request somehow did not make it into any of the recent releases....

[LeanTolo]

Any update on this bug?

[PureWeen]

Can someone provide an example app (preferably a google written app) that exhibits this behavior? None of the platforms apps I've tested on Android work like this. The behavior in XF was generally hostile to keyboard users and TalkBack users. If we were to re-instate this behavior in .NET MAUI we'd fail internal accessibility testing. If there's an implementation of this behavior that exhibits proper keyboard/accessibility practices then we can look at implementing those.

If you hook up an external keyboard you can see how poorly this works in XF

• add 5 entries
• tab to the third one
• hit "Windows button + back" (which is equivalent to hitting the back button).
• the focus pops back up to the first entry because we are unfocusing the current entry but Android has to focus something so it puts the focus back on the first one.

Changing focus on users without them causing it is typically a very jarring and inaccessible experience.

Still no advance on this? It's not just the back action, tapping somewhere else on the screen should dismiss the keyboard (unless tapping another entry, ofc). It worked in XF. Please fix this on MAUI.

The way this behavior worked in XF was to make the entire page clickable which made apps completely inaccessible. Anybody wanting to pass WCAG certification with an XF app were forced to write custom code to disable this behavior. The only place where I've seen this behavior is if the area you click off to is interactable in some format. For example, the maps app if you click off to the results but if you test with the WIFI app or contacts app they don't work like this. If you want to add this behavior yourself I think this would be the best way to go about it https://stackoverflow.com/a/28939113 so you don't confuse TalkBack.

I think we need to flesh out the use cases here a bit more so we can provide guidance or additional APIs to give people the ability to make these choices if they want to but we're not going to make this the default behavior unless provided some examples that are accessible and preferable over the default Android behavior or if it can demonstrated that .NET MAUI breaks Android platform defaults.

.NET MAUI is in BAD need of xplat keyboard APIs which I feel is at the core of most of these issues.

[philipag]

@PureWeen I'm not sure but perhaps I conflated the unfocus issue with other bugs related to entry selection and soft keyboard. As you say it appears focus should not change when the soft keyboard is closed, so my description in this issue is inaccurate.

Here is a sample which shows some soft keyboard related bugs, but not the exact bug I see in our app (I am unable to easily replicated our app issue in a sample). I hardwired some of the sizes so you need to use a pixel5 emulator screen size to see the entry items at the bottom.

layoutbug7.zip

The green entry works normally. When tapping it, the soft keyboard opens and the green entry is shifted up so the user can see what is being typed. When the keyboard closes, the green entry shifts back down.

The red entry uses TranslationY which seems to break this logic. When tapping the red entry, not only is the red entry not shifted up (it remains hidden behind the keyboard), but strangely only the green entry gets shifted up instead even though text is entered into the red entry. For now we can consider this to be the bug for this issue.

In our app we are seeing additional bugs which are that shifting the entry up into view works, but when the soft keyboard is closed the shifted UI is not shifted back down (this is the regression from XF I meant to report in this issue). Unfortunately I don't have a sample, but perhaps the attached bug sample will shed enough light on the issue for some general fixes which also address our app's issue.

[PureWeen]

@philipag interesting I'll need to see how Android keyboard works with Translation code. I know in XF there was a bunch of code that tried to always reposition and re-layout the Page if the keyboard shrunk it. If I remember correctly it would actually modify the size of the page so everything would layout to the new size.

Unfortunately we haven't had time to re-evaluate that code and move it over. Keyboard behavior in XF is very broken because of trying to be "too smart" and we unfortunately haven't had time to properly assess and bring some of that over in a way that is accessible.

[philipag]

@PureWeen In our app I am now also able to replicate the bug of the wrong view being shifted up when the soft keyboard opens. This happens even without TranslationY being used (I set the position using AbsoluteLayout.SetLayoutBounds() instead).

So it really seems like there are some bugs related to soft keyboard under Android. Not sure how Android determines which view to move up (which input control is being edited via the soft keyboard), but it seems that somehow MAUI is providing the wrong view to Android which then shifts it up.

Anyway, my provided sample shows this bug so hopefully that will make it easy to find+fix.

[philipag]

@PureWeen I just ran the sample on an iOS emulator (VS 17.4.0 Preview 2.0) and there the soft keyboard covers the green and red Entry so under iOS it seems there are similar issues?

It seems that the iOS issue has been reported as #4792

[philipag]

One more related issue is that with the new MAUI behavior (no un-focusing the Entry control when the soft keyboard closes like XF did) is that if the user closes the keyboard with the Android back button, there is no way for the app to know this and it's logic will continue to think that the user is editing the Entry control even though he is not.

So I think with the new MAUI behavior of not loosing focus there needs to be an additional event added so the app can tell when the keyboard is closed so the app can adjust its layout etc. Currently there is no way of doing this anymore.

Similarly when the soft keyboard "accept" button is pressed, the Entry.Completed callback gets called but the soft keyboard is not closed and there does not appear to be a way to close it programmatically from within MAUI (without writing native code). This also seems to be a shortcoming of the new MAUI keyboard handling and it seems that MAUI should have ways of (1) detecting whether the soft keyboard opens and closes and (2) allow the app to close the soft keyboard programmatically.

With XF this was not necessary since the entry control looses focus when keyboard is closed with the back button....

[Samirgc]

+1 badly need this issues fixed for my prod app.

[joaquin171993]

Al dia de hoy sigo presentando el problema de que el teclado no se cierra al presionar el boton de Listo
en .Net MAUI

[Syed-RI]

+1

[Syed-RI]

Provide us an API to dismiss the soft keyboard at least

[Samirgc]

Is enabled = false and unfocus() will hide the keyboard temporarily workaround but the issue is different the keyboard will overlap the entry on iOS

[PureWeen]

I realize this issue has collected a few different issues so in order to organize I created a new issue for the keyboard covering up your entry.

Can everyone that commented about the keyboard covering your entry please stand up and join me over here. I've posted a workaround in there which should resolve that part of this until we can roll out a fix.