Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 for Bug 58263 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 23673 [details]
Button Custom Renderer to handle Keyboard
This one took me a bit to debug, and I think I have an -OK- grasp on what is happening enough to actually write a bug on it. At least I think it's a bug... it might very well be my understanding of things that are off here.
My application is a Xamarin.Forms application which makes use of a custom Button control specifically for iOS, which is the topic of this defect.
I have a custom renderer for a Button (CustomButton_IOS.cs -- attached to this bug) where I'm setting Notification Events when the soft keyboard is displayed in IOS. I do this because I want my "Continue" button at the bottom of the form scrolled up above the soft keyboard while the user is entering text.
The use case is a user enters text into the Entry field and should be able to click the "Continue" button which makes use of the attache custom renderer.
What appears to be happening is when the "Hide" notification and delegate are invoked (UIKeyboard.WilHideNotification), if I move the button (by setting this.Center to a new position), the Xamarin.Forms assigned "Clicked" event will not fire.
If I move the button relocation to a new thread (using Task.Factory) within the same delegate, the Xamarin.Forms "Clicked" event fill fire.
I'm not sure if this is truly a threading issue or a timing issue. I suspect one of two things is happening:
1) Moving the button location within the delegate gets schwify with the Touch Events and perhaps "TouchUp" isn't invoked since the button is moved to a location that isn't currently being touched
2) Calling the button move in a new thread delays the move just long enough for the touch up event to fire before the button is moved.
Either way, this one burned me out.
Any help is appreciated!
My system information is as follows:
Visual Studio Community 2017 for Mac (Preview)
Version 7.1 Preview (7.1 build 1281)
Installation UUID: 61ae6405-cfca-4fba-ba0e-f5bc6b8bd8eb
Mono 18.104.22.168 (2017-04/3d531ba) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 502000209
SDK Version: 1.0.3
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/msbuild/15.0/bin/Sdks
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
Apple Developer Tools
Xcode 8.3.3 (12175.1)
Version: 10.12.0.14 (Visual Studio Community)
Build date: 2017-07-05 11:08:04-0400
Version: 22.214.171.124 (Visual Studio Community)
Android SDK: /Users/ericnusbaum/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
6.0 (API level 23)
SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.6
SDK Build Tools Version: 25.0.3
Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Android Designer EPL code available here:
Version: 126.96.36.199 (Visual Studio Community)
Build date: Fri, 21 Apr 2017 17:57:12 GMT
Release ID: 701001281
Git revision: cc3abfe9b515ed0e209041e00d3ea239e8e33df9
Build date: 2017-07-10 21:15:50-04
Xamarin addins: 73710b74251e471826f2d9981d3a2bee6c4e78ad
Build lane: monodevelop-lion-d15-3
Mac OS X 10.12.5
Darwin 16.6.0 Darwin Kernel Version 16.6.0
Fri Apr 14 16:21:16 PDT 2017
This does seem to be a timing issue and is related to bug 45723. What's happening in this case is that touching the page while the keyboard is open will fire off a UITapGestureRecognizer we've added to automatically close the keyboard. The touch event does still get passed to the Button, however since we're wired up to TouchUpInside event your guess about the Button being moved at the same time does seem to be correct.
To avoid this you would need to add a delay like you've already done. If you like, you could simplify it by just adding a 1ms delay instead of creating a new thread. But ultimately this would be recommended approach in order to accomplish this right now.
There is a pull request for bug 45723 to add a platform-specific feature that allows you to set controls as first responder on iOS. This would prevent the touch gesture from going to the page so you would be responsible for closing the keyboard, but that would allow the Clicked event to be fired beforehand.
I am going to keep this report open as confirmed so the team can review it further and determine if this behavior should be kept or changed. Thanks!
Would a workaround for this issue be remapping the TouchUpInside to TouchDownInside within the renderer? This would move it up the ole' event stack and possibly address this issue without any timing hackery.
I had started down this path at one point but wanted to file the defect as it seemed non-trivial, but in this case, perhaps the correct answer.