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 for Bug 13543 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 4465 [details]
parts of three screenshots showing problem
Description of Problem:
After logging into a session on a system that has gone to 'black screen', the sidebar/bottombar areas of XS grow in size--see attached images.
The area increases in size with each iteration of screen-saver=>log in=>restore XS.
The recalc is happening with each cycle, whether or not XS is restored for work between screen-saver events.
NOTE 1: This is on a multi-monitor system. And it's the more usual situation in which the monitors are not the same size.
This subwindow inflation can be undone (with sizes returning to exact normal display) by going from the code/text editor into the layout-xml editor, then going back to the code editor. This requires double-clicking in the 'solution' pane to force a restart of the graphical xml editor tool within its graphical editor mode.
Steps to reproduce the problem:
1. Start XS, leave it in a source code window.
2. Be sure to have the tool-fly ins collapsed in their default positions.
3. Let system go to screen saver then power-saver monitor black-out.
(XS can be visible [maxed or normal doesn't matter] or minimized at this point.)
4. Log in, bring XS up if minimized. left-hand and bottom subwindow areas will have increased in size.
5. Let system go back to screen saver/black out.
6. Log in. XS's subwindow areas will have grown more in size.
This repeats as long as you don't force a recalc of the side window areas by starting the graphical xml editor, then returning to the code editor.
Editor changes dimensions automagically.
How often does this happen?
On my system, it happens every time the screen saver/black out cycle is repeated.
If XS remains minimized during any of these cycles, the growth still happens--so some part of GTK(?) isn't checking for that state.
Win 7 Ultimate [64b] with NVidia GeForce GTS 240 graphics controller [1Gb dedicated video ram].
Dual monitor:  1920 x 1200  1680 x 1050 ('True color' 59Hz)
This appears to be a cosmetic problem--nothing seems to fail as a direct result.
However, it might indicate GTK instabilities, particularly in multi-monitor issues.
(Such are not uncommon: on resumption, the Android emulator [along with DOS console windows] also fails to remember which monitor it was originally on--a problem XS doesn't have.)
Created attachment 4503 [details]
Even wider expansion after a couple of days spent minimized
This seems to be limited to situations in which XS is started and you deal solely with C# within the code editor: the visual layout editor is never started, even if the project reads (source) xml files into [background] editor windows when you load an existing project.