Bug 55246 - Focusing on a UITextField is slow when using Xamarin.Google.iOS.MobileAds
Summary: Focusing on a UITextField is slow when using Xamarin.Google.iOS.MobileAds
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 10.10 (d15-2)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2017-04-16 20:58 UTC by Paul Gomes
Modified: 2017-06-15 02:42 UTC (History)
5 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

sample Xamarin.iOS project (12.48 KB, application/zip)
2017-04-27 17:26 UTC, Jimmy [MSFT]

Description Paul Gomes 2017-04-16 20:58:33 UTC
1. Valid GoogleAdMob publisher id
2. Physical iOS device (the problem is not exposed with the simulator)

Repro Steps:
1. Create a new Xamarin.Forms Shared application that includes iOS.
2. In the default generated App() constructor add three Entry controls to the layout.

So that the constructor is now:

	public App()
		// The root page of your application
		var content = new ContentPage
			Title = "EntryTest1",
			Content = new StackLayout
				VerticalOptions = LayoutOptions.Center,
				Children = {
					/// Add three Entry Controls
					new Entry(),
					new Entry(),
					new Entry(),
					new Label {
						HorizontalTextAlignment = TextAlignment.Center,
						Text = "Welcome to Xamarin Forms!"

		MainPage = new NavigationPage(content);

3. Add the package Xamarin.Google.iOS.MobileAds and ensure packages are up-to-date
4. Build and Run the application on the device 
5. OBSERVE: the caret of the Entry control quickly appearing indicates that the Entry control has focus as one selects Entry control after Entry control

*** Now add one line of code that will cause a second delay for the Entry control to receive focus. 

6. In the AppDelegate.cs file of the iOS project add:


to method:

public override bool FinishedLaunching(UIApplication app, NSDictionary options)

7. Build and Run the application on the device
8. OBSERVE: the caret of the Entry control is slow to appear (is unresponsive for one second) as one selects Entry control after Entry control

*** Now switching to another application will improve the responsiveness to normal

9. While the application with the slow responsive test app is running switch to another application (such as safari).
10. Switch back to the test application
11. OBSERVE: The caret quickly moves to the Entry control that is being selected.  The unresponsive problem is gone.
Comment 1 Jimmy [MSFT] 2017-04-27 17:26:05 UTC
Created attachment 21862 [details]
sample Xamarin.iOS project

I was able to reproduce the issue described with a sample project. After adding and initializing the Xamarin.Google.iOS.MobileAds package there was a noticeable lag from tapping on the Entry and the keyboard and cursor appearing. I tested this on an iPhone 5s with iOS 10.3.

However, this does not seem to be a Xamarin.Forms specific issue as the it also happens with a non-Forms Xamarin.iOS app. I’ve attached this sample project to the report. In this case it may be an issue with the component itself therefore I am re-assigning this report to the components team so they can look into this.

### Component

Xamarin.Google.iOS.MobileAds 7.16.0

### Version Info

=== Xamarin Studio Enterprise ===

Version 6.3 (build 863)
Installation UUID: 94ce5106-6a72-4691-b34e-cd5857b1db66
	Mono 4.8.1 (mono-4.8.0-branch/22a39d7) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408010000

=== NuGet ===


=== Xamarin.Profiler ===

Version: 1.4.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 8.3 (12169)
Build 8E162

=== Xamarin.iOS ===

Version: (Visual Studio Enterprise)
Hash: a04678c2
Branch: d15-1
Build date: 2017-03-28 14:05:38-0400

=== Xamarin.Android ===

Version: (Visual Studio Enterprise)
Android SDK: /Users/jimmygarrido/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.3   (API level 10)
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)
		7.0   (API level 24)
		7.1   (API level 25)

SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.3
SDK Build Tools Version: 25.0.2

Java SDK: /usr
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

Android Designer EPL code available here:

=== Xamarin.Mac ===

Version: (Visual Studio Enterprise)

=== Xamarin Inspector ===

Version: 1.2.2
Hash: b71b035
Branch: d15-1
Build date: Fri, 21 Apr 2017 17:57:12 GMT

=== Build Information ===

Release ID: 603000863
Git revision: a2163670efe259c85cd8f335d95b175068fbbe2a
Build date: 2017-04-03 14:33:15-04
Xamarin addins: 2045d688ea1420e0381b473360ca62a763eb7d04
Build lane: monodevelop-lion-d15-1

=== Operating System ===

Mac OS X 10.12.4
Darwin Jimmys-MBP.guest.corp.microsoft.com 16.5.0 Darwin Kernel Version 16.5.0
    Fri Mar  3 16:52:33 PST 2017
    root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

xUnit.NET 2 testing framework support 0.6.14
Redth's Addins 1.0.7
Comment 2 Israel Soto 2017-06-15 02:42:41 UTC
Xamarin and Xcode test cases: https://www.dropbox.com/s/37on3sh7zxx5v8g/AdMobTestCases.zip?dl=0

Steps to reproduce the issue in Xamarin:

1. Open AdMobTest_Xamarin/AdMobTest solution.
2. Run the project on a device.
3. Tap between UITextFields to see the delay.

- If you close and open the app, the delay disappear.
- If you remove the line `Google.MobileAds.MobileAds.Configure("ca-app-pub-YOUR~PUBID");`, the delay disappear.


I ported the sample to Xcode to verify if the delay was related to Google Mobile Ads framework but with no success. The sample works as expected in Objective-C.

Updating the Google Mobile Ads component didn't resolve the problem.

Tried to use Xamarin Profiler but the test case gets frozen with Profiler when you try to change the focus of UITextField, see bug #57513 for more information.

Moving to iOS team for a deeper investigation.

Note You need to log in before you can comment on or make changes to this bug.