|Summary:||Picker.Focus() does not work on Windows 8.1 and UWP (Windows Desktop)|
|Component:||Windows||Assignee:||Paul DiPietro [MSFT] <paul.dipietro>|
|Severity:||normal||CC:||jas, paul.dipietro, rui.marinho, v-sapaun|
|Tags:||Is this bug a regression?:||---|
|Last known good build:|
|Attachments:||Sample app demonstrating Picker.Focus() function having no effect|
Description Dan 2017-02-03 06:47:39 UTC
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 (v184.108.40.206) 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.
Comment 1 Rui Marinho 2017-03-20 15:57:49 UTC
Should be fixed in 2.3.5-pre1
Comment 2 Saurabh Paunikar 2017-07-13 09:10:25 UTC
Verified on xamarin.form version 220.127.116.116-pre6. Tested on both Windows 8.1 and UWP ScreenCast link : https://www.screencast.com/t/zG4LlRRn
Comment 3 Dan 2017-09-06 01:59:19 UTC
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 v18.104.22.1689-pre2 NuGet package. It would be great if this issue could be fixed to work consistently for buttons and labels. Thanks!
Comment 4 Paul DiPietro [MSFT] 2017-09-06 02:50:43 UTC
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.
Comment 5 Dan 2017-09-08 16:17:25 UTC
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.
Comment 6 Paul DiPietro [MSFT] 2017-09-13 04:05:06 UTC
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.