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 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
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.
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.
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.
Just realized I sent Support the wrong files. Will follow up with correct versions later today.
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.
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?
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.
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?
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.
OK, I created a project that reproduces both problems.
- 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
- 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)
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:
(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?
I added report video.
I am using OS X 10.10.2
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
Chris, are you able to see what I see? Any idea of what is going on or how we can move forward?
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.
Hmm, odd. I'll ask my folks to try to reproduce to see if anyone here can't.
Did you see the video I attached of what I see?
Your video did not have you attempting to scroll left-right in the expanded table row view.
I was able to reproduce it one time, but it very finicky.
According to this documentation:
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
and then having your MainWindow override the following method:
public override void VisualizeConstraints (NSLayoutConstraint 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:
"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.
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.
Thank you! Not sure how I missed that, sorry to have wasted the time!
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!
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.
Xamarin Support Team
*** This bug has been marked as a duplicate of bug 26894 ***