Bug 13543 - sidebar subwindow-areas holding dockable window tags expand after screen saver
Summary: sidebar subwindow-areas holding dockable window tags expand after screen saver
Status: NEW
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Docking ()
Version: 4.0.10
Hardware: PC Windows
: --- normal
Target Milestone: master
Assignee: Bugzilla
Depends on:
Reported: 2013-07-28 10:04 UTC by eduard.qualls
Modified: 2013-08-01 06:57 UTC (History)
1 user (show)

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

parts of three screenshots showing problem (72.18 KB, image/png)
2013-07-28 10:04 UTC, eduard.qualls
Even wider expansion after a couple of days spent minimized (27.54 KB, image/png)
2013-07-31 12:46 UTC, eduard.qualls

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 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 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:

Description eduard.qualls 2013-07-28 10:04:11 UTC
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.

NOTE 2: 
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.

Actual Results:
Editor changes dimensions automagically.

Expected Results:
Editor stability.

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.

Additional Information:
Win 7 Ultimate [64b] with NVidia GeForce GTS 240 graphics controller [1Gb dedicated video ram].
Dual monitor: [1] 1920 x 1200 [2] 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.)
Comment 1 eduard.qualls 2013-07-31 12:46:47 UTC
Created attachment 4503 [details]
Even wider expansion after a couple of days spent minimized
Comment 2 eduard.qualls 2013-08-01 06:57:24 UTC
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.