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 17598 [details]
A ContentPage with WebView that has a file picker control fails to show photo picker when ContentPage is pushed modally. This warning is displayed when trying to open the WebView tries to open the UIImagePickerController:
>Warning: Attempt to present <UIImagePickerController: 0x7ba68800> on <Xamarin_Forms_Platform_iOS_ModalWrapper: 0x7e379c90> whose view is not in the window hierarchy!
Works as expected when page with WebView is pushed non-modally.
## Steps to reproduce
1. Open the attached test project and deploy the iOS app to a device or simulator.
2. Tap on "Click Me" button.
3. Tap on "Click TO Navigate" button.
4. You are no in the WebView. Tap on the "Choose Photo" button
5. Tap on the "Photo Library" button in the alert.
Expected result: Will be asked for permission to access the photo library and will be able to choose a picture from the library.
Actual result: Page with WebView disappears and the previous page is shown. Warning noted above is observed in the application output.
If pages are pushed non-modally instead of modally, the photo picker shows as expected and a photo can be chosen.
## Regression status
Does not appear to be a regression. Tested all 2.x versions of Forms with the same results.
=== Xamarin Studio Enterprise ===
Version 6.1 (build 5441)
Installation UUID: ceaba76c-db06-4fbd-b326-f69ea53c3e01
Mono 4.6.0 (mono-4.6.0-branch/746756c) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 406000245
=== NuGet ===
=== Xamarin.Profiler ===
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Xamarin.Android ===
Version: 184.108.40.206 (Visual Studio Enterprise)
Android SDK: /Users/jongoldberger/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
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)
SDK Tools Version: 25.2.2
SDK Platform Tools Version: 24.0.3
SDK Build Tools Version: 24.0.2
Java SDK: /usr
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Android Designer EPL code available here:
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Apple Developer Tools ===
Xcode 8.0 (11246)
=== Xamarin.iOS ===
Version: 10.0.0.6 (Visual Studio Enterprise)
Build date: 2016-09-09 13:01:32-0400
=== Xamarin.Mac ===
Version: 220.127.116.11 (Visual Studio Enterprise)
=== Xamarin Inspector ===
Build date: Tue Apr 26 23:07:44 UTC 2016
=== Build Information ===
Release ID: 601005441
Git revision: 68292d1ab289911c815ddc715dd7cc29a9752f9f
Build date: 2016-09-09 04:43:23-04
Xamarin addins: ed25d008672663eeb9db55f1ccecb3c24d2fd3b2
Build lane: monodevelop-lion-cycle8
=== Operating System ===
Mac OS X 10.11.6
Darwin Jons-MacBook-Pro.local 15.6.0 Darwin Kernel Version 15.6.0
Mon Aug 29 20:21:34 PDT 2016
=== Enabled user installed addins ===
Xamarin Inspector 0.8.0.0
Any update on this issue?
I worked on iOS modal pages to fix another problem, but it might fix yours. See https://github.com/xamarin/Xamarin.Forms/pull/432.
Perhaps it makes sense to wait until it's reviewed/merged and test your use-case again.
Should be fixed on 2.3.6-pre1