Bug 41869 - [iOS] Margins set on a StackLayout that is a direct child of a ViewCell are not respected.
Summary: [iOS] Margins set on a StackLayout that is a direct child of a ViewCell are n...
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: iOS ()
Version: 2.3.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on: 60966
Blocks:
  Show dependency tree
 
Reported: 2016-06-15 21:09 UTC by Jon Goldberger [MSFT]
Modified: 2018-02-13 02:07 UTC (History)
5 users (show)

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


Attachments
Test Project (223.53 KB, application/zip)
2016-06-15 21:09 UTC, Jon Goldberger [MSFT]
Details


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 for Bug 41869 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Jon Goldberger [MSFT] 2016-06-15 21:09:36 UTC
Created attachment 16349 [details]
Test Project

## Description

Margins set on a StackLayout that is a direct child of a ViewCell are not respected, e.g.:

><ViewCell>
>     <StackLayout Margin="20,8" BackgroundColor="Olive">
>        <Label Text = "{Binding Name}" />
>        <Label Text = "{Binding Type}" />
>     </StackLayout>	
></ViewCell>

On Android, the view cell will have the set margins, but on iOS the margins are not set... unless I wrap the existing StackLayout in another StackLayout, e.g.:

><ViewCell>
>      <StackLayout> <!-- Not needed for Android, but needed for iOS for margins set below to be respected -->
>         <StackLayout Margin="20,8" BackgroundColor="Olive">
>            <Label Text = "{Binding Name}" />
>            <Label Text = "{Binding Type}" />
>         </StackLayout>	
>      <StackLayout>
></ViewCell>

So it would seem to me that the first stack layout is perhaps becoming the UITableViewCell on iOS and iOS likes UITableViewCells to be the full width of the UITableView? 

## Steps to reproduce

1. Open the attached test project. (Derived from FormsListViewSample)

2. Launch to an iOS Device or simulator

Expected result: Items in the list will have a 20 px margin on the sides and an 8 px margin on top and bottom. 

Actual result: Items in the list have no margins, are flush to the sides and no space between. 

## Notes

Launch the Droid project to see the expected result, or uncomment the extra StackLayout in MainViewXaml.xaml and run on iOS again. The correct margins will be displayed. 

Tested on Form version 2.2.0.45 and 2.3.0.46-pre3

## Environment

=== Xamarin Studio Enterprise ===

Version 6.0 (build 5174)
Installation UUID: ceaba76c-db06-4fbd-b326-f69ea53c3e01
Runtime:
	Mono 4.4.0 (mono-4.4.0-branch-c7-baseline/5995f74) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404000182

=== Xamarin.Profiler ===

Not Installed

=== Xamarin.Android ===

Version: 6.1.0.71 (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)

SDK Tools Version: 25.1.7
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.3

Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Android Player ===

Version: 0.6.5
Location: /Applications/Xamarin Android Player.app

=== Xamarin Inspector ===

Version: 0.8.0.0
Hash: dc081aa
Branch: master
Build date: Tue Apr 26 23:07:44 UTC 2016

=== Apple Developer Tools ===

Xcode 7.3.1 (10188.1)
Build 7D1014

=== Xamarin.iOS ===

Version: 9.8.0.323 (Visual Studio Enterprise)
Hash: 39ebb77
Branch: cycle7
Build date: 2016-06-01 21:23:15-0400

=== Xamarin.Mac ===

Version: 2.8.0.323 (Visual Studio Enterprise)

=== Build Information ===

Release ID: 600005174
Git revision: 694a75f040b7f2309bc43d4f78a3a6572ca898bf
Build date: 2016-06-01 17:28:08-04
Xamarin addins: 33f406fa2dcf214012c78cb846585f062b2e1d24
Build lane: monodevelop-lion-cycle7-baseline

=== Operating System ===

Mac OS X 10.11.5
Darwin Jons-MacBook-Pro.local 15.5.0 Darwin Kernel Version 15.5.0
    Tue Apr 19 18:36:36 PDT 2016
    root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

Xamarin Inspector 0.8.0.0
Comment 2 adrianknight89 2016-10-21 16:26:08 UTC
Referencing https://bugzilla.xamarin.com/show_bug.cgi?id=43427
Comment 3 adrianknight89 2016-10-21 17:22:04 UTC
Another related issue: https://bugzilla.xamarin.com/show_bug.cgi?id=44690

I think right now it's safer to apply margin and translation and possibly other forms of layout adjustments to the direct child of a container view instead of applying them to the view cell instead.
Comment 4 Paul Brenner 2018-02-12 21:19:31 UTC
I cannot find the PR that fixed this, but I ran the sample project, and saw the issue, then upgraded to 2.5.0.122203, and could not reproduce the issue any more. Can someone from QA confirm this is fixed?