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 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.
Created attachment 19708 [details]
Sample app demonstrating Picker.Focus() function having no effect
I'm using Windows 10 (Version 10.0.14393 Build 14393), and have only tested this with the Windows 8.1 and UWP apps (not Android, iOS, or Windows Phone, so it may be a problem there as well). Calling a Picker's Focus() function from the UI thread does not put the Picker in focus and cause it to prompt the user to pick one of the items as expected.
I have attached a sample application that reproduces the problem by attempting to do this from both a Button's Click event and a Label's Tapped event, but neither work. This is reproducible using both the latest stable version of Xamarin.Forms (v220.127.116.11) and the newest 2.3.4-pre1 pre-release version. The only files modified from a Vanilla Xaml Forms App was MainPage.xaml and MainPage.cs in the shared portable project, and updating the Xamarin Forms NuGet package (although the older version also had the same problem).
This forum post (https://forums.xamarin.com/discussion/59573/problem-reliably-giving-focus-to-a-picker-from-a-button-click-handler-on-ios?) describes the same problem, but they only mention it not working on iOS.
This bug (https://bugzilla.xamarin.com/show_bug.cgi?id=41232) reports the same problem for the DatePicker control, so perhaps this requires the same solution, I'm not sure.
Should be fixed in 2.3.5-pre1
Verified on xamarin.form version 18.104.22.1686-pre6. Tested on both Windows 8.1 and UWP
ScreenCast link : https://www.screencast.com/t/zG4LlRRn
The issue has definitely been improved since it works some of the time, but it still does not work all of the time. You can even see this in the screencast video you posted, where near the end you click on the button and it does not put the picker in focus and you have to click the button a second time.
In my own testing, I am seeing the same result. You often (not every time, but often) have to click the button 2 times for it to focus the picker. Clicking on a label has even worse results, as it seems to work about one out of every 4 or 5 times you click on it. In the screencast video I'm not sure if you tried clicking the label or not, but it doesn't show clicking the label as putting the picker in focus.
I am still seeing this same behavior on the Xamarin.Forms v22.214.171.1249-pre2 NuGet package. It would be great if this issue could be fixed to work consistently for buttons and labels. Thanks!
We're aware of this. The original change was based upon using GotFocus and is not an optimal way of doing things as tabbing between pickers will open them, which isn't intended. That said, a standard UWP app does not open the dropdown when Focus(FocusState value) is called on it, so we may revert the change entirely depending on how further investigation into the issue goes.
Yeah, I agree that using GotFocus is a sort of round-a-bout way of programmatically getting the picker to open up, and like you said, it's not the default behavior when tabbing through the controls. Perhaps a better solution would simply be to expose a new OpenPicker() function (maybe with a better name) on the control that would put the control in focus and open it up.
The original PR has been reverted as discussed due to the nature of the UWP behavior becoming something unexpected for users, and it being best to leave it alone for the time being. I'm uncertain if this will be approached again in the future so it's probably simplest to mark this as not on roadmap for the time being.