Bug 11689 - Application Output scroll bars artifact on main screen
Summary: Application Output scroll bars artifact on main screen
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Shell ()
Version: 4.0.3
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Cody Russell
: 8143 ()
Depends on:
Reported: 2013-04-09 14:28 UTC by Jason Hartley
Modified: 2017-07-17 14:46 UTC (History)
7 users (show)

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

screen shot of scroll bar artifact bug (261.03 KB, image/png)
2013-04-09 14:28 UTC, Jason Hartley
Fixed? (217.55 KB, image/png)
2016-10-19 15:20 UTC, Jason Imison

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:

Description Jason Hartley 2013-04-09 14:28:45 UTC
Created attachment 3784 [details]
screen shot of scroll bar artifact bug

When the Application Output window is docked on the main screen (such that it has a tab next to Documents), and when running the application in debug mode such that focus is automatically given to the Application Output window, then when the tab for Documents is selected the vertical and horizontal scroll bars for Application Output persist as visual artifacts on the Documents window.  See attachment.
Comment 1 Mikayla Hutchinson [MSFT] 2013-04-09 16:52:16 UTC
What keyboard layout?
Comment 2 Mikayla Hutchinson [MSFT] 2013-04-09 17:14:09 UTC
Er, wrong bug, sorry.
Comment 3 Mikayla Hutchinson [MSFT] 2013-04-09 17:14:59 UTC
Mitch - woud it be possible to hide the overlay scrollbars for a widget if it's unmapped?
Comment 4 Kristian Rietveld (inactive) 2013-04-11 16:09:31 UTC
When a GtkScrolledWindow is unmapped, the layers for the overlay scrollbars are hidden. So for unmapped widgets, the scrollbars should not appear.

Isn't this a duplicate of bug 8143?
Comment 5 Mikayla Hutchinson [MSFT] 2013-04-11 16:51:37 UTC
I think so, yes. Unfortunately that bug's private as it has screenshots of private code, so let's make this one the primary.
Comment 6 Mikayla Hutchinson [MSFT] 2013-04-11 16:53:38 UTC
*** Bug 8143 has been marked as a duplicate of this bug. ***
Comment 7 Mikayla Hutchinson [MSFT] 2013-04-11 17:05:20 UTC
Well, we definitely have scrollbars being shown for a widget that's no longer visible, so something strange is going on. Contrary to mitch's suggestion in bug 8143, I don't think the solution is clipping - the scrollbars aren't extending outside of a visible widget, they're being shown for a hidden widget. This might have something to do with how we're hiding the widget - IIRC we just deparent it.
Comment 8 Kristian Rietveld (inactive) 2013-04-12 03:02:21 UTC
There are cases where dock items slide "over" the editing area, so that the editing area and dock item are visible, but the editing area's scroll bar is still drawn. This scroll bar is then drawn on top of the dock item and the solution here would be to clip.

About unmapping, I was a bit too fast yesterday evening. If a parent is unmapped, its child may not be. So GtkScrolledWindow would need to track whether its parent is mapped.
Comment 9 Kristian Rietveld (inactive) 2013-04-12 03:49:23 UTC
From my understanding, the state in the opening comment of the bug can only be reproduced by placing pads in the same dock such that they become tabs. When you resize the dock, then the scroll bars of all tabs in that dock will appear. Scroll bars of invisible tabs will not fade out.

To handle this we cannot simply check whether the parent is mapped (it will be), but need to handle the method the docking system uses to implement notebooks.

For other docking  configurations I have so far been unable to get to a state where scrollbars were shown for an invisible pad.
Comment 10 Mikayla Hutchinson [MSFT] 2013-04-15 16:57:59 UTC
Ah, right, the case where an autohidden pad is mapped over the mainview, but the main view's scrollbars are still showing. That's a tricky one.

I think the main trigger is when the dock layout changes, e.g. when starting debugging.
Comment 11 Michael Natterer 2013-04-18 10:27:01 UTC
Can you point me to the code that manages dock page visibility?
Comment 12 Jason Imison 2016-10-19 15:20:25 UTC
Created attachment 18126 [details]

I wasn't able to reproduce this. I made sure that both the application output pane and the text editor had enough content to scroll and that the application output pane was docked next to the editor. Then I switched from the output pane to the editor while the app was still running.

Is this still a problem with the latest version of Xamarin Studio?
Comment 13 Greg Munn 2017-07-17 14:46:46 UTC
Closing. Please reopen if you are still experiencing the issue and can provide the requested information. Thanks.