Bug 26638 - Mac app renderers the UIView different when build includes Mono runtime
Summary: Mac app renderers the UIView different when build includes Mono runtime
Status: RESOLVED DUPLICATE of bug 26894
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: 1.10.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2015-02-02 10:53 UTC by Prashant Cholachagudda
Modified: 2015-02-10 01:15 UTC (History)
4 users (show)

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


Attachments
XIB demonstarting the issue (103.17 KB, application/octet-stream)
2015-02-02 10:53 UTC, Prashant Cholachagudda
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 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:
Status:
RESOLVED DUPLICATE of bug 26894

Description Prashant Cholachagudda 2015-02-02 10:53:58 UTC
Created attachment 9600 [details]
XIB demonstarting the issue

One of the views in customers Xam.Mac application includes nested NSScrollViews. 
The idea is that the outer view scrolls vertically, and items inside the inner view scroll horizontally. 
The view required a custom implementation of the view so that the inner view handles horizontal scrolling and passes vertical scroll events to the next responder. 

It appears that the view renders differently when the mono runtime is included vs. when not. 
So their in-development version of the app works just fine, but the packaged version of the app does not. 
You can reproduce this by ticking the “Include Mono runtime in the application bundle” on their development machine
Comment 1 Michael Teper 2015-02-04 12:44:19 UTC
Discovered another potentially related issue. We have a vertical split view that separates the UI into a primary area and a side area. There is a toolbar button the toggles the visibility of the split view, and when toggled off, the split view animates away. The behavior is very similar to Xcode panes, and the implementation follows the approach outlined in Apple WWDC sessions. Works fine when the Mono framework is not included in the build, and fails ("Unable to simultaneously satisfy constraints") when the Mono framework is included.

There is some interplay between the inclusion of the Mono framework and auto-layout that is breaking our app in at least two places now. This is a critical issue for us.
Comment 3 Chris Hamons 2015-02-05 09:58:31 UTC
Could you attach a project with the view.cs and view.designer.cs for that raw nib file and XTHorizontalScrollView and associated bits. 

Or even better, a full project showing the issues so I don't have to spend a bunch of time reverse engineering the issue first.

https://gist.github.com/chamons/0f3678fadd94e9c87603
Comment 4 Michael Teper 2015-02-05 10:58:24 UTC
Chris, I sent files you requested via support@. Unfortunately, no go on the full project. However, the following might serve as an additional clue:

I tried creating a small app in which to reproduce the animation layout constraint conflict and was not able to do so. That is, I created the app, but could not reproduce the problem. As I experimented further, I started to suspect that timing might be a factor, and it turned out that while in my small app hiding the split view subview in the end-of-animation block did not cause problems, in the real app it does -- somehow, when the Mono framework is included, Cocoa is not fully "caught up" at the end of animation and hiding the subview resulted in a layout constraint violation. Adding a 150 millisecond delay "fixed" it.

Now, I don't know how that is related to differences in layout and scrolling not working when Mono framework is included, but maybe it will give a clue.
Comment 5 Michael Teper 2015-02-05 10:59:00 UTC
Just realized I sent Support the wrong files. Will follow up with correct versions later today.
Comment 6 Chris Hamons 2015-02-05 11:06:30 UTC
Relevant files attached to support case.

Sounds like it could just be a timing issue. When we package up with mono, a bunch of things happen that might be changing timing.
Comment 9 Michael Teper 2015-02-05 12:17:47 UTC
I just attached correct versions of relevant files to this case, sorry about the confusion!

RE: your last comment, "... could just be a timing issue ...": so what is the next action here?
Comment 10 Chris Hamons 2015-02-05 12:27:25 UTC
So I talked to Preshant about reaching out to you, but here's the status.

I'm unable to repro the case locally with the files attached. There was a lot of reactui code and stuff i ripped out to get the view to show up, but i don't see the issue.

Since you said it appears to be a timing issue:

" Cocoa is not fully "caught up" at the end of animation and hiding the
subview resulted in a layout constraint violation. Adding a 150 millisecond
delay "fixed" it."

It sounds like the app is running faster/slower with mono embedded than when you use the system mono. We do a bunch of things when we embed, any of those could be causing the timing change.

Right now, I'm having a hard time seeing a bug. It sounds like you are assuming certain timing behaviors and checking the embed mono box is throwing them off.

If you really think it is a bug in Xamarin.Mac/Mono, I think we need a full example project showing the issue in detail.
Comment 11 Michael Teper 2015-02-05 18:14:33 UTC
Chris, what I said was that a completely separate aspect of the app was behaving differently with and without Mono included and that I tracked it down to timing. This screen specifically lays out differently with and without Mono, so I don't know whether timing is an issue or not.

With this view, the issue is that the nested scroll view (inside the table view) is not scrolling when the app is built with Mono included. Were you able to rebuild enough of the screen to see that?

As you can tell, this is a fairly complex screen. Is there anything I can do on my end to help you troubleshoot?
Comment 12 Chris Hamons 2015-02-05 18:21:09 UTC
I think the only way I'm going to be able to look at this is for you to build an example showing the behavior you feel is wrong. A zipped up project, full of your nib, code behind, and such that I can build, instead of hacking a few files into a project and trying to get it build. It doesn't have to be your full app, or even your app code, but something that you can point at concretely and say "this is wrong". Because right now, I'm not seeing the bug.
Comment 13 Michael Teper 2015-02-05 21:59:46 UTC
Chris, what I said was that a completely separate aspect of the app was behaving differently with and without Mono included and that I tracked it down to timing. This screen specifically lays out differently with and without Mono, so I don't know whether timing is an issue or not.

With this view, the issue is that the nested scroll view (inside the table view) is not scrolling when the app is built with Mono included. Were you able to rebuild enough of the screen to see that?

As you can tell, this is a fairly complex screen. Is there anything I can do on my end to help you troubleshoot?
Comment 14 Michael Teper 2015-02-05 22:04:01 UTC
OK, I created a project that reproduces both problems.

Scrolling issue:
- Run project as is
- Click the disclosure triangle and observe a really long line
- Scroll this line right and left to see the whole thing (use a trackpad, touch mouse, or option key + scroll wheel)
- Now, quit, change the project setting to include the Mono framework and run again, and observe that you can't scroll horizontally any more

Constraints issue:
- Run project
- Click the disclosure triangle to expose strings
- Click the Toggle button and watch the project output (might have to toggle more than once to get the conflict)
Comment 16 Chris Hamons 2015-02-06 11:05:29 UTC
@Michael,

I hate to tell you this after all of the work you spent creating a repro case, but I can't seem to reproduce the issue you are seeing locally.

Here is a videocast:

https://www.dropbox.com/s/8xi5hk0w8lftyz5/26638.swf?dl=0

(You can drag it to a web browser frame to play).

Maybe you could look at it and tell me what i'm missing? (Excuse how slow the video is, jing was really slowing down my laptop).

What version of OS X are you running? Maybe the timing is only on a certain OS version?
Comment 18 Michael Teper 2015-02-06 12:03:42 UTC
I added report video.
Comment 19 Michael Teper 2015-02-06 12:05:14 UTC
I am using OS X 10.10.2

Hardware:
  Model Name:	MacBook Air
  Model Identifier:	MacBookAir6,2
  Processor Name:	Intel Core i5
  Processor Speed:	1.3 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	3 MB
  Memory:	8 GB
Comment 20 Michael Teper 2015-02-09 12:03:47 UTC
Chris, are you able to see what I see? Any idea of what is going on or how we can move forward?
Comment 21 Chris Hamons 2015-02-09 12:04:49 UTC
I'm still unable to reproduce the issue locally (I'm not seeing what your video shows). I'm attempting to get other people here at Xamarin to try to repro it. I'll get back to you.
Comment 22 Michael Teper 2015-02-09 12:20:53 UTC
Hmm, odd. I'll ask my folks to try to reproduce to see if anyone here can't.
Comment 23 Chris Hamons 2015-02-09 12:24:49 UTC
Did you see the video I attached of what I see?
Comment 24 Michael Teper 2015-02-09 12:41:28 UTC
Your video did not have you attempting to scroll left-right in the expanded table row view.
Comment 27 Chris Hamons 2015-02-09 14:13:13 UTC
I was able to reproduce it one time, but it very finicky. 

According to this documentation:

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/ResolvingIssues/ResolvingIssues.html

I believe the problem is that during some animation a set of constraints you've set are unable to be satisfied and you get the error. Changing the embedded nature of mono, different machines, etc, are making the problem more or less visible.

You can figure out which constraints are causing the problem by setting the following in your DidFinishLaunching

NSUserDefaults.StandardUserDefaults.SetBool (true, 
"NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints");

and then having your MainWindow override the following method:

		public override void VisualizeConstraints (NSLayoutConstraint[] constraints)
		{
			base.VisualizeConstraints (constraints);
		}

That should hit when you hit this case. From that, you should be able to figure out which constraints you've set in Xcode are causing the issue. 

The third answer here:

http://stackoverflow.com/questions/11721656/how-to-set-nsconstraintbasedlayoutvisualizemutuallyexclusiveconstraints

"One disadvantage of keeping this setting around is that other people's software suddenly gets highlighted for ambiguous layouts - even on occasion stuff from Apple itself."

Makes me think this is not a super uncommon issue, so I'm wondering why this is blocking.
Comment 28 Michael Teper 2015-02-09 14:24:59 UTC
Chris, we seem to be talking at cross-purposes and I think we've exceeded the bandwidth afforded by this medium. Please, let's have a voice conversation. Let me know when and how I can best reach you.
Comment 29 Michael Teper 2015-02-09 16:26:29 UTC
Thank you! Not sure how I missed that, sorry to have wasted the time!
Comment 30 Michael Teper 2015-02-09 16:28:26 UTC
That last comment, "Thank you! Not sure how I missed that, sorry to have wasted the time!", was meant for another bug. Please ignore (or, delete, if possible). Sorry!
Comment 31 Brendan Zagaeski (Xamarin Team, assistant) 2015-02-10 01:15:48 UTC
Coordinating phone calls is generally only possible on rare occasions with the support team, and even rarer occasions with the developer teams.

But after review I don't think we'll need any phone calls in this case anyway. I was able to reproduce the original symptom of this bug quite easily using the test case. So I think the best way to reduce confusion is to split the original problem into a new bug report and mark this bug as a duplicate.

For now, we'll completely discard the problem with "Unable to simultaneously satisfy constraints" (from comment 1, possibly resolved by comment 27). If needed, please file a separate bug report for that issue.


Best,
Brendan Zagaeski
Xamarin Support Team

*** This bug has been marked as a duplicate of bug 26894 ***