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 10546 [details]
navigation issues in iOS, forms and monotouch
Our app requires custom navigation,
so we've made our own content page, which can display other content pages - by extending pagerenderer.
This technique works fine, and everything is as expected... except
when we embed a navigation page inside our our, we find that the back button, although clicked, doesn't respond to the clicks (i.e doesn't pop the viewcontrollers).
It does however go back if you swipe, or do it programatically.
I have verified that a nested UINavigationcontroller performs 100% fine in native ios, and in a monotouch app (i..e ios without forms).
I've attached all my examples.
I have checked this issue with attached sample project and I am also getting same behavior.
Build output: https://gist.github.com/Parmendrak/fc5eecf25bb2a9d9db7d
Please let me know if can give more information regarding the same.
=== Xamarin Studio ===
Version 5.8.2 (build 5)
Installation UUID: 1a096c6f-0678-402e-89b2-a2c10f7e80e4
Mono 3.12.1 ((detached/0849ec7)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312010003
=== Apple Developer Tools ===
Xcode 6.2 (6776)
=== Xamarin.iOS ===
Version: 220.127.116.11 (Business Edition)
Build date: 2015-03-20 06:51:49-0400
=== Xamarin.Android ===
Version: 18.104.22.168 (Business Edition)
Android SDK: /Users/360_macmini/Desktop/android-sdk-macosx
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)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
Java SDK: /usr
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
=== Xamarin Android Player ===
Version: Unknown version
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 22.214.171.124 (Business Edition)
=== Build Information ===
Release ID: 508020005
Git revision: 541c06a4f6c95383333375d56fd6c23ce48cb916
Build date: 2015-03-20 09:23:08-04
Xamarin addins: 02510c4990dee3475c282b3182d588975a63ff07
=== Operating System ===
Mac OS X 10.9.4
Darwin ShrutiMac.local 13.3.0 Darwin Kernel Version 13.3.0
Tue Jun 3 21:27:35 PDT 2014
We'd be happy to help you resolve this issue. Please help us by attaching a reduced reproduction to the bug by starting with a clean Xamarin.Forms project and adding just the code necessary to demonstrate the issue. If you'd do this for us we would very much appreciate it. If you are able to reproduce the issue without modifying the platform specific projects that would eliminate a number of possibilities and likely expedite a resolution. If you need to create a custom renderer please tell us how we can extend the forms platform so you no longer need to create one. Custom renderer scenarios "break the warranty" of forms, so to speak, as we're unable to test these scenarios. Instead, we prefer to extend the platform so they are no longer necessary to create.
Xamarin Forms Team
I've actually implemented my own solution which works just fine using renderers to show sub-pages. Please read the last comment here https://forums.xamarin.com/discussion/comment/126589#Comment_126589
a video is included to show you what I'm talking about.
Something you wrote here concerns me deeply.
"Custom renderer scenarios "break the warranty" of
forms, so to speak, as we're unable to test these scenarios. Instead, we prefer
to extend the platform so they are no longer necessary to create. "
One thing that attracts myself and my company to Xamarin Forms is the sheer power we get from renderers. As it stands, you guys don't provide access to underlying renderers (and therefore viewcontrollers/uiviews/viewgroups). We have to work around this for now using reflection, and have assumed it's just an oversight. It's essential to us as it allows us to keep our applications agile and responsive to whatever need, even if Forms doesn't yet support features we require.
It sounds like you are suggesting that Xamarin disapprove of us creating our own extensions with renderers, which facilitate compositional extension of your platform (such as adding gesture recognizers, or custom layouts, things that aren't just "new controls").
Can you please clarify? If that was the case I'd almost certainly give up all my efforts now and tell my company to steer well clear.
I think some official advice on the if/when you are going to make the renderer properties available for Xamarin forms views is long overdue. I'd appreciate your clear guidance.
And to clarify, I am an advanced Xamarin user. I do things like make apps with multi page video chat, web browsing, webRTC, highly custom UI navigation, native speed xaml cell performance. I worked as Adobe consultant for many years with Flex, and as such have a good feel for how to get the most out of your platform.
I assumed that this tinkering and releasing to the community was welcomed, and was expecting you guys to open up a few things to assist us (make the renderer property of View public, implement hooks in your IGestureRecognizer interface so we can actually make our own, provide an interface mechanism for row heights in listviews, so we can take advantage of our fast scrolling).
Perhaps I'm mis-reading; but it sounds to me like you guys might not be wanting advanced users on your platforms, who have power to do these things; but n00bs who think Xamarin is just some slightly-faster-cross-platform html engine?
Created attachment 11401 [details]
example of problem
Hi Chris, I've added a new example for you. This one demonstrates the problem clearly.
I have my component for allowing embedding of pages (which has a custom renderer), which adds the navigation page.
you will observe the back button doesn't work on tap.
Swip to go back works.
Tellingly, if you tap, and drag on the button, even a few pixels. it will work. Could it be that you guys are adding tap gesture recognizers to everything inside the page to facilitate your tap gesture recognizer? This is my hunch anyhow.
+1 for this bug, George did a great job providing a PageViewContainer that let us create advanced UI without using custom Renderer, that's why it'd be so nice to fix this
why is this need info? what more do you guys need?
I am confirming this issue:
The root of the problem is due to the hosting of the Page inside a View. Several mechanisms internal to forms and its navigation stack assume that pages nest pages or views and views only nest views. This results in breaks in the navigation chain if this is not true. We currently don't support this case, however we may in the future.
That defect is the one where I ask for the feature for page embedding, which I was chasing up for weeks with my account rep.
So are we getting page in page or not? And if so, wouldn't it be wise to fix this?
If not, how do we chase that feature and this one up? We desperately need page in page embedding, as per the reasons I laid out in 28526, and in the forums, and in my blog posts.
I was understanding that it's done; but I don't see how, if you're now saying "We currently don't support this case, however we may in the future". Either the person who did 28526, doesn't understand what they did, or you've suddenly had a change of heart about it and are going to hold 28526 back.
Also, is there any easy workaround?
Any movement on this? I was told this feature was coming months and months ago. I mean we are on version 2.0 now...
Im not sure how we got to the point of miscommunicating that 2.0 would somehow include Pages inside of Views. To be clear, there is no intention to ever allow nesting of Pages inside of Views.