Bug 33664 - InputTransparent behaves differently on different platforms
Summary: InputTransparent behaves differently on different platforms
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.5.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2015-09-04 11:14 UTC by John Miller [MSFT]
Modified: 2016-09-12 15:31 UTC (History)
10 users (show)

Tags: ac
Is this bug a regression?: ---
Last known good build:

Test Case (176.76 KB, application/zip)
2015-09-04 11:14 UTC, John Miller [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description John Miller [MSFT] 2015-09-04 11:14:05 UTC
Created attachment 12754 [details]
Test Case


   When InputTransparent is set to True on iOS, tap gestures are received by the parent of that view. On Android, the view still receives the tap gestures.

**Steps to Reproduce:**

   1. Run the attached sample on an iOS simulator
   2. Tap on a number (they are labels with TapGestureRecognizers attached)

   Repeat these steps on Android to see a difference.

   Toggle comments on line 35 to change the InputTransparent setting to see different behaviors when True vs. False.

**Actual Results:**

   When InputTransparent = true
   iOS: The log messages show that the StackLayout (parent) is receiving the tap instead of the labels. 
   Android: The log messages show that the labels receive the tap gestures. 

**Expected Results:**

   The customer hitting this issue is expecting the Labels to receive the tap gestures when InputTransparent = true, but the Grid should not receive any taps. Android seems to behave this way.

**Build Date & Platform:**

   XF 1.5.0-pre3

**Additional Information:**

   The docs (http://developer.xamarin.com/api/property/Xamarin.Forms.VisualElement.InputTransparent/) state:

> true if the element should be able to receive input; false if element should not receive input and should pass inputs to the element below. Default is true.

There is a known issue that the docs are wrong about the "Default is true". The default is false, and will be updated in the docs soon. 

It also seems unclear to me what the expected behavior should be. Given the semantics of "InputTransparent", it seems backwards that True would make the element receive input. I would expect a "input transparent" (true) element to _not_ receive input.

Note to team* Please make the docs clearer on how this property should work and confirm the True/False behavior.
Comment 3 philip 2015-09-11 01:34:41 UTC
Unfortunately IOS does things differently from Android/WinPhone and disabling input using UserInteractionEnabled=False disables user input for all child views as well.

To make this work as expected (consistent with other platforms), XF would have to implement InputTransparent=False by doing something like in the correct answer here instead of using UserInteractionEnabled=False:

Comment 4 philip 2015-09-12 15:21:37 UTC
Alternatively and more simply, it should be enough to make a view background transparent and then it should allow its children to process touch event.  This does not work either under iOS.
Comment 5 John Hardman 2016-01-15 11:18:20 UTC
As Philip says, iOS behaves differently from the other platforms (I am working on Android, iOS, WinPhone and Windows). There are multiple bugs in bugzilla about behaviour of InputTransparent. My concern is that in attempting to fix these, the other platforms will end up behaving like iOS, rather than iOS behaving like the other platforms. If the other platforms are made to behave like iOS, that will be a massive breaking change for existing code.
Comment 6 Bart King 2016-01-29 11:07:06 UTC
I have a layout like this (kept simple for this post):

    <ColumnDefinition Width="30" />
    <ColumnDefinition />
  <Button Grid.ColumnSpan="2" />
  <StackLayout InputTransparent="true" Grid.Column="1">
    <Label InputTransparent="true" Style="{StaticResource BigText}" />
    <Label InputTransparent="true" Style="{StaticResource SmallText}" />

Basically, I am layering a two lines of text (with different styles) on top of a button.

Under Android, I can tap anywhere on the button and the button depresses and reacts accordingly. Under iOS, the button depresses only if I tap in the 30 pixel edge on the left, anything that the StackLayout covers does not bubble down to the button.

Is this the same issue as being reported here? To workaround it, I presume I'll have to draw the text on top of the button myself (at least on iOS)...
Comment 7 Bart King 2016-01-29 11:33:24 UTC
Hmm, disregard that... Updating to Xamarin updates that were pushed to stable today and Forms seems to have resolved it for me. Made no other changes.
Comment 8 E.Z. Hart [MSFT] 2016-04-13 18:20:09 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Forms. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction.
For your convenience, we have created some reproduction best practices viewable here: https://gist.github.com/jassmith/92405c300e54a01dcc6d

Warm regards,
Xamarin Forms Team
Comment 9 adrianknight89 2016-09-12 02:35:17 UTC
If this issue is fixed, why is it still in the CONFIRMED state?