Bug 23011 - Input Accessory View No Longer Can Receive Focus
Summary: Input Accessory View No Longer Can Receive Focus
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 8.0.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-09-15 11:44 UTC by Matt Cuda
Modified: 2014-09-22 14:12 UTC (History)
6 users (show)

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

Showing inputs (228.94 KB, image/png)
2014-09-15 11:44 UTC, Matt Cuda
2014-09-16 16:05 UTC, Matt Cuda

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Matt Cuda 2014-09-15 11:44:59 UTC
Created attachment 8066 [details]
Showing inputs

I have input accessory views on several of my keyboards but they no longer respond to button taps. In fact, the buttons do not even highlight for focus.  It behaves as if the accessory view is being send backward in the z order.

This occurs on all keyboards using accessory views.

Dump of Version:

=== Xamarin Studio ===

Version 5.4 (build 216)
Installation UUID: 66c4e974-b8ab-4313-83b6-abf4a857e41e
	Mono 3.8.0 ((no/45d0ba1)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 308000009

=== Xamarin.Android ===

Version: 4.16.0 (Enterprise Edition)
Android SDK: /Users/mattc/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0   (API level 14)
		4.0.3 (API level 15)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Apple Developer Tools ===

Xcode 6.0 (6299)
Build 6A313

=== Xamarin.iOS ===

Version: (Enterprise Edition)
Hash: 436246d
Build date: 2014-09-10 00:04:26-0400

=== Xamarin.Mac ===


=== Build Information ===

Release ID: 504000216
Git revision: bf73535e350da9a84b6990c72149b84467757c52
Build date: 2014-09-09 15:40:19-04
Xamarin addins: cb699c7d52f13def4e9746f8086e9f24ef6d894f

=== Operating System ===

Mac OS X 10.9.4
Darwin minint-9f8kv0b.corporate.ecmd.com 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 1 Matt Cuda 2014-09-15 11:45:33 UTC
This is iOS 8 by the way
Comment 2 Sebastien Pouliot 2014-09-16 09:44:04 UTC
Is this working in earlier iOS releases (e.g. 7.x) ?

There is no change in XI 8.0 for this. OTOH there are known changes in Xcode6 simulator support wrt keyboards (e.g. external ones) and how it can affect an `inputAccessoryView`. 

Can you give us more details, e.g. a test project so we can confirm this ?
Comment 3 Matt Cuda 2014-09-16 09:53:54 UTC
Yes, worked fine previously.  Same code has been in prod for at least a year.  I don't use the simulator.  It is showing up on Phones loaded with iOS 8 and using Xamarin.

Our other app running on iOS 8 and using accessory views (written in XCode) work fine.
Comment 4 Matt Cuda 2014-09-16 14:58:02 UTC
Yep, just confirmed, if I target iOS 7 in the build properties and run it on an 5s phone it runs fine.  When I change my target to iOS 8 and run on the 5s running iOS 7, it doesn't work.

Note that I can duplicate this in the iOS 8 simulators as well.  It appears to only be a Xamarin issue.  Infragistics also confirmed this because initially I thought it was one of their controls failing.
Comment 5 Sebastien Pouliot 2014-09-16 15:13:02 UTC
It could be, OTOH there is no iOS version-specific code in those bindings and I've seen/googl'ed other similar issues affecting ObjC apps.

Please provide a test case that shows the issue (and if you have a similar test case in ObjC it would be welcome) and we'll have a look into it.
Comment 6 Matt Cuda 2014-09-16 15:16:58 UTC
So you created your own test code and it worked for you or are you just trying to get me to do your work?

I am getting tired of sending over projects I have to write to prove your crap is broken.
Comment 7 Matt Cuda 2014-09-16 15:18:55 UTC
By the way, code works fine in objective c.  I have another app we use that has the same kind of input views.
Comment 8 Matt Cuda 2014-09-16 16:05:32 UTC
Created attachment 8082 [details]

Here is the test case you requested.
Comment 9 Matt Cuda 2014-09-17 16:23:26 UTC
Did you have a chance to look at it?
Comment 10 Cody Beyer (MSFT) 2014-09-18 16:13:02 UTC
I have confirmed this bug using the sample provided.
Comment 11 Sebastien Pouliot 2014-09-18 21:19:39 UTC
The sample, as-is, does not work on iOS8. Still there's no difference in (Xamarin) code being executed (compared to iOS7). In fact it also works fine when using code, e.g.

        public override void ViewDidLoad()
            txtTruckNumber.Delegate = new  txtTruckNumberHandleEnter();
			var tb = new UIToolbar (new RectangleF (0, 0, 320, 50));
			tb.SetItems (new [] {
				new UIBarButtonItem (UIBarButtonSystemItem.Cancel),
				new UIBarButtonItem (UIBarButtonSystemItem.FlexibleSpace),
				new UIBarButtonItem ("Minus", UIBarButtonItemStyle.Plain, null),
				new UIBarButtonItem (UIBarButtonSystemItem.FlexibleSpace),
				new UIBarButtonItem (UIBarButtonSystemItem.Done)
			}, false);
			txtTruckNumber.InputAccessoryView = tb;
            // Perform any additional setup after loading the view, typically from a nib.

so I suspect the issue is in the XIB file (it would not be the first time). Those files contains more than just UI definitions (i.e. configuration) making them hard to debug. 

c.c. Alan (designer team) which may be able to visually spot the wrong setting(s) or might have seen similar iOS7/8 differences.
Comment 12 Matt Cuda 2014-09-19 08:16:01 UTC
To use the code above is not a solution to us at this time.  We have this xib plugged in to a large project so we need a solution to the xib issue.
Comment 13 Alan McGovern 2014-09-22 10:23:03 UTC
I've just spent some time investigating this. A more detailed discussion of the problem can be found on our forums: http://forums.xamarin.com/discussion/23529/inputview-issues-in-ios8 .

I believe the issue is simply a change in how iOS 8 handles Parent/Child relationships between UIViewControllers.

In DetailViewController.ViewDidLoad you directly assign truckNumberInputView.View to txtTruckNumber.InputAccessoryView. This is not correct as the NumberPadInputViewController is the 'owner' of that view and there are special APIs which must be invoked when moving a View from one ViewController to another ViewController.

This worked in iOS < 8 by chance, but no longer works in iOS8+.

If this testcase is an accurate representation of your app, here are three workarounds to cope with the behavioural change in iOS8. 

1) iOS8 added special support for this exact case. The introduction of this new method is probably the reason why your code breaks. You could dynamically detect if you are running under iOS8+ or iOS7.1 and then either use your current approach or use this new approach: https://developer.apple.com/library/IOs/documentation/UIKit/Reference/UIResponder_Class/index.html#//apple_ref/occ/instp/UIResponder/inputAccessoryViewController

2) Apply this change to your code
- txtTruckNumber.InputAccessoryView = truckNumberInputView.View;
+ var view = truckNumberInputView.View;
+ truckNumberInputView.View = null;
+ txtTruckNumber.InputAccessoryView = view;

If you set 'truckNumberInputView.View' to null before adding the view as the InputAccessoryView you will set up the correct UIView hierarchy and everything will work as expected.

3) Rewrite 'NumberPadInputViewController' to have a base class of UIView instead of UIViewController. This is a little more complicated, but it is an option.

Can you let us know if one of these approaches fixes the issue in your actual application?
Comment 14 Matt Cuda 2014-09-22 13:38:14 UTC
Thanks, got it working.  I ended up going with #3 as the final solution.  #1 was confusing on implementing with Xamarin.  #2 didn't work.
Comment 15 Alan McGovern 2014-09-22 14:12:58 UTC
Great, I'm glad one of those options worked for your app.

Do let us know if you have any other issues. I'm just going to resolve this as a 'feature' as this is the expected behaviour of iOS8+.