iOS iPad Entry Control: Tab on an external keyboard does not move between UI Elements

[stevedcc]

Description

When using an iPad, the tab key on the on-screen-keyboard will succesfully move between entry controls. Unfortunately, when using an external keyboard, the tab key does not work.

Steps to Reproduce

1. Create a new "Hello World" MAUI App
2. Add two Entry controls to the MainPage.xaml
3. Run the App, focus on one of the Entry controls
4. Use the tab key on the On-Screen-Keyboard to switch between the Entry controls
5. Attach an external keyboard via Bluetooth
6. Attempt to use the tab key to switch between the Entry controls - nothing happens.

Link to public reproduction project repository

No response

Version with bug

8.0.3

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

iOS 17

Did you find any workaround?

No

Relevant log output

No response

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[tj-devel709]

Looking into this one. Something I do notice is that when the hardware keyboard is connected to the iPad, the soft keyboard's tab button no longer changes the entry either.

Edit - the behavior is that nothing happens when pressing tab with the software keyboard when the external keyboard is connected.
When the hardware keyboard is not connected, the software keyboard's tab goes to the next entry as expected.

[tj-devel709]

It also seems that the Full Keyboard Access setting affects how the hardware keyboard navigation works when enabled: https://www.idownloadblog.com/2020/03/13/ipad-keyboard-navigation-tutorial/. I will keep looking to see if there is a way to keep the same behavior when using the 'tab' key when this is not enabled

[tj-devel709]

In an xcode project, the tab key on an external keyboard on iPad with Full Keyboard Access turned off causes the next entry to be focused so this seems to be specific on Maui.

[tj-devel709]

Can also confirm that this works fine in Xamarin Forms with and without the Full Keyboard Access turned on.

[tj-devel709]

Okay, we were able to identify the issue! The problem seems to lie with the window.VisualDiagnosticsOverlay blocking the tab button with the hardware keyboard on iPad as shown in the method below.

		public static void MapContent(IWindowHandler handler, IWindow window)
		{
			_ = handler.MauiContext ?? throw new InvalidOperationException($"{nameof(MauiContext)} should have been set by base class.");

			var nativeContent = window.Content.ToUIViewController(handler.MauiContext);

			handler.PlatformView.RootViewController = nativeContent;

			if (window.VisualDiagnosticsOverlay != null)
				window.VisualDiagnosticsOverlay.Initialize();
		}

The workaround for this issue is to replace that mapper and remove those lines with the window.VisualDiagnosticsOverlay. You can add the code below to your MauiApp builder for example.

	.ConfigureMauiHandlers(_ =>
	{
#if __IOS__
		if(UIKit.UIDevice.CurrentDevice.UserInterfaceIdiom == UIKit.UIUserInterfaceIdiom.Pad)
		{
			WindowHandler.Mapper.ReplaceMapping<IWindow, WindowHandler>(nameof(IWindow.Content), (handler, window) => {
				var _ = handler.MauiContext ?? throw new InvalidOperationException($"{nameof(MauiContext)} should have been set by base class.");

				var nativeContent = window.Content.ToUIViewController(handler.MauiContext);

				handler.PlatformView.RootViewController = nativeContent;
			});
		}
#endif
	});

[stevedcc]

Thank you for finding the cause and a workaround.

[drasticactions]

@stevedcc The issue is because the WindowOverlay (used for handling overlay graphics on top of App Windows and diagnostics tooling, such has handling universal tap events) captured the tab event because the literal UIView layer being on top. Even though the user interaction events were being passed through (hence, clicks and taps worked fine) the view had to have its focus turned transparent to allow the tab event to work.

My PR linked above should fix it. It seems like it only affected iOS though. Mac Catalyst worked fine.

[stevedcc]

Thanks for the summary,

Unfortunately, I have a customer who needed to replace a Xamarin app with a MAUI app and has had to live with this bug for 5 Months. I'm very grateful to you for finding and fixing this, and regret that the state of MAUI has meant that the consultancy I work for has decided to no longer offer green field MAUI projects, as a direct result of the extremely difficult migration from Xamarin to MAUI.

Fundamentally the problems were:

• We had to start planning migrations early in 2023, based on .NET 6
• It became clear that bugs were not being backported to supported .NET versions at a later date
• We had to upgrade one customer to .NET 7 and another to .NET 8 during migration
• There were lots and lots of basic UI bugs which we had to work around
• We were over budget on both projects, primarliy because MAUI was a moving target with so many bugs
• The response time for fixing bugs has been extremely slow: this one took 5 months, another I opened has been open since around February 2023

Unfortunately we don't seem to be the only firm which has found MAUI to be less than satisfactory. As far as I can tell, a large number of developers with MAUI experience are choosing Swift and Kotlin for their future.

[colemcarthur]

@tj-devel709 This issue appears to still occur if you have entries within a scroll view even with the workaround in place. Is there a way to fix this as well?