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.
This is an issue that has been biting us for some time. GTK doesn't always release mouse grabs.
I'm able to randomly reproduce this bug on vanilla HEAD of upstream gtk-2-24, using
only testtreeview and gtk-demo. Investigating.
Do you guys have a way to *reliably* reproduce that? Ever since I started debugging it won't happen, truly a Heisenbug.
This upstream issue seems related: https://bugzilla.gnome.org/show_bug.cgi?id=566963
I've never heard of a reliable way to reproduce it, unfortunately. IIRC It's got a lot better since client-side windows were introduced - it used to be really easy to trigger.
To reliably reproduce the bug:
* start testtreeview
* give testtreeview window focus
* click on the Mac menu bar
* click on triangle in tree view -> won't respond.
Ok, with the procedure in comment 6 it does not get as stuck as in the screencast, because switching windows will make the expander work again which is not the case in the screencast.
Created attachment 267 [details]
Patch that fixes the issue described in comment 6
To start with, this patch fixes the issue described in comment 6. It turns out that after clicking the menu bar, events delivered to the application do not have the window field in NSEvent set. Because of that GDK would ignore the event. This patch tries to identify whether this event hits one of the application's windows before fully giving up on the event.
Before this can hit GTK+ master, I still want to clean up/refactor things a bit, because there's quite some code duplication around getting/finding toplevels from events now.
Also I need to spend more time with MonoDevelop to get the expander as stuck as in the screen cast.
We are having a hard time getting the real issue reproduced. As far as we have been told by now, the real issue puts GTK+ in the following state:
- TreeView triangles are not responsive to mouse clicks.
- Pressing arrow keys emits sounds. The keys to expand/collapse rows work.
- Switching focus to another window and back does not resolve the issue.
- Other widgets in the UI function as usual.
Any more detail about how to get into this state is would be appreciated.
From comment 4:
> This upstream issue seems related:
Beware that it looks like there are two issues being discussed in this upstream bug. In the more recent comments (with a patch from Rui Matos), a GTK+3-specific bug is discussed.
In the first 10 comments of that bug, an issue is described that sounds familiar to the issue described in this Xamarin bug. However, personally, I have never been able to reproduce it. From what I understand, Anjuta and MonoDevelop have the docking system in common; could this be triggering this specific issue?
I doubt it, MonoDevelop has its own C#-based docking library, and we don't see the problem on Linux or Windows.
Ok then they are definitely not related, thanks for confirming. (The UI of the docking libraries really looks quite similar though :)
*** Bug 1071 has been marked as a duplicate of this bug. ***
The duplicate bug has a way to reproduce it.
Not sure this is exactly the same bug, because in the case of 1071, keyboard navigation doesn't work either.
Last night I had an ultra-reliable repro for this:
1) Double clicked on a sln to open in MD
2) *click* on the tab in the sidebar to forcibly open the solution pane
3) It refuses to recognize future clicking, but it does accept keyboard navigation.
4) Once you keyboard navigate it usually accepts mouse input again but it could break. If it does break again, keyboard navigating again fixes it.
If you hover over the solution pane to open it, it doesn't break.
However this didn't quite work for me now when i was trying to repro it for Nat, but he managed to repro the bug with this sequence.
We are able to reproduce this issue, please go with the steps:
1. Launch the MonoDevelop (prerequisites: MonoDevelop window should not be maximized)
2. Create a solution or open existing .sln file.
3. Click on triangle icon observe that they would be working.
3. Maximize the MonoDevelop window.
4. Click on triangles and see that now they are not working.
We seem to be dealing with three bugs here:
1) Expanders don't work after clicking on / using the Mac menu bar. This is covered in comments 6 to 8 with a patch in comment 8.
2) Maximizing a window breaks expanders. See comment 17 and bug 1071. A prerequisite for the procedure in comment 17 is that the window must be small enough prior to maximization. Maximizing a close-to-maximized window will not reproduce the problem.
Because clicking somewhere else gives you a single chance to use an expander again, I think this is a different bug from the real one described in the opening comment.
This problem can be reproduced with testtreeview as well, which should be helpful for debugging.
3) The *real* issue seems to be triggered by the procedure in comment 16. So far, I've only managed to trigger the bug once. It feels like you need to click on the tab in the sidebar at the right moment to trigger it. Or perhaps the tab has to be hidden in a particular way beforehand.
Created attachment 643 [details]
This patch fixes case 2 from comment 18
This patch fixes case 2 from comment 18. Since it is so trivial and clean, I've immediately pushed it to the gtk-2-24 branch in the upstream repository.
I am wondering if the sliding docks code makes use of toplevels that resize and move position at the same time. If yes, then perhaps this patch improves things for case 3 (aka "the real bug") as well. I will see if it becomes to reproduce with knowledge of this patch.
I can consistently reproduce this issue with three simple steps:
1) open any project
2) open any file of the project
3) click on Window -> Close all menu option
After that, I can't expand the solution tree anymore.
Unfortunately that repro doesn't work for me.
> 1) open any project
> 2) open any file of the project
> 3) click on Window -> Close all menu option
> After that, I can't expand the solution tree anymore.
Though if you click elsewhere in the window, the expanders will work again as usual. This case is fixed by the patch in comment 8.
I pushed my patch from comment 8 to the gtk-2-24 branch after performing the refactoring I mentioned (due to the refactoring I also realized we can limit the slow fallback just to motion events with window = NULL).
Now with having the two most user-visible issues fixed in the gtk-2-24 branch, I would say it is a good idea to push these fixes in a release and see if users can still reproduce any related problem?
We'd like to do that ASAP but unfortunately the GTK 2.24 branch has breaking changes to the handling of modifiers, and we need to track those in MonoDevelop first.
This appears to fix #1754.
*** Bug 2003 has been marked as a duplicate of this bug. ***
*** Bug 313 has been marked as a duplicate of this bug. ***
*** Bug 1492 has been marked as a duplicate of this bug. ***
*** Bug 1887 has been marked as a duplicate of this bug. ***
*** Bug 1083 has been marked as a duplicate of this bug. ***
This should be fixed by the GTK+ version that's currently in Mono beta, so I'm marking it fixed. Please re-open if it happens with GTK+ version is 2.24.8 or later. GTK+ version can be found in the MD About dialog.
*** Bug 3549 has been marked as a duplicate of this bug. ***
I am seeing this bug in the 2.9.4 Alpha version of Monodevelop.
It seems pretty intermittent but can trigger it by opening the Properties window for a given file in the solution.
Mono 2.10.9 (tarball Tue Mar 20 15:31:37 EDT 2012)
*** Bug 4407 has been marked as a duplicate of this bug. ***
I'm getting this a lot recently as well, typically in the WatchPad
I'm seeing too on both 2.9.4 and 2.9.5: http://screencast.com/t/WpjTmZgwkX9
Installation UUID: bfe4d389-101c-473e-bbcd-d2e0678bb8bb
Mono 2.10.9 (tarball Tue Mar 20 15:31:37 EDT 2012)
Apple Developer Tools:
Xcode 4.3.2 (1177)
Mono for Android: 18.104.22.168858872
Release ID: 20905000
Git revision: 688e551a68f688fc36da48aae3d636f2b342b247-dirty
Build date: 2012-04-12 17:52:45+0000
Xamarin addins: 3b20fe54e002c6fdf3da8b1033a9e3e304c758b2
Mac OS X 10.7.3
Darwin Chris-MacBook-Air.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
The latest issue reported by Eric might be a dup of 4388.
Also wondering whether we should mark bug 3997 as a dup of this.
I think we need to consider bug 4388 as part of this - the symptoms are identical, though it appears to be possible to work around it by reverting a memory leak fix. What's odd about that one is that it's reproducible on Windows.
Michael, if I build MonoDevelop 362edd8fc73da7e2e30906897c4831065b04262f and have a project with a failing unit test, is it then guaranteed I can reproduce the problem? Because that would give a good starting point for debugging.
Related question, is there a simple project with failing unit test available somewhere or do I need to create my own for testing purposes?
The repro with the context menu isn't any good, it was a separate issue as described in bug 4388 - something about gtk_menu_attach behaving strangely, on both Mac and Windows. Eric's repro looks like it was that too. There's not enough info about Chris's, and Jeff's probably referring to bug 3997, which is still open. So I'm gonna close this one again for now.
Today we have checked this issue on following builds :
XS 4.0.9 (build 3)
Now we are able to expand and close solution tree.
Hence closing this issue. Changing its status to verified.