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 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.
What keyboard layout?
Er, wrong bug, sorry.
Mitch - woud it be possible to hide the overlay scrollbars for a widget if it's unmapped?
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?
I think so, yes. Unfortunately that bug's private as it has screenshots of private code, so let's make this one the primary.
*** Bug 8143 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
Can you point me to the code that manages dock page visibility?
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?
Closing. Please reopen if you are still experiencing the issue and can provide the requested information. Thanks.