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.
How to reproduce:
1) load a solution containing a failing unit test
2) switch to unit test view
3) bring up the context menu in the unit test tree and run the test
4) in the test results panel, try to expand a failure node by clicking the arrow icon
It may be necessary to repeat once or twice from step 3 or step 1 to trigger the problem. Git bisect said:
362edd8fc73da7e2e30906897c4831065b04262f is the first bad commit
Author: Michael Hutchinson <firstname.lastname@example.org>
Date: Thu Apr 5 00:12:39 2012 -0400
[TextEditor] Fix parent handling in ShowContextMenu
Handles existing parent, detaches when done
(which is why I submitted this bug for the text editor, and not the nunit component)
btw. I've that on various tree views - like the version control review. It is really annoying and worses monodevelop usability.
I suspect it has something to do with the gtk fixes.
If I revert the commit I mentioned in the first comment, everything seems to work fine again.
That doesn't make sense, unless gtk_menu_detach is broken. Oh well, maybe we don't need to call it.
The menu does get detached when destroyed, so the only reason to detach it on hide was in case it got re-shown and attached again. I know of only one place (the tasks pad) that re-uses a context menu, and that could be changed easily.
On second thoughts, I think we need to detach it to prevent a leak...
I see this on Windows too.
Need to debug whether the detaching is necessary, since that's the only thing that happened in this patch.
Confirmed it will leak unless we detach it.
Removed the attaching and detaching as a workaround. Attaching isn't very important, it just makes the menu move when the parent widget moves and be destroyed with the parent widget.
I did some digging into how this thing behaves to try to figure out what exactly is going wrong. I could get a similar (or worse) grab problem by altering the way that MD's treeview context menu subclass intercepts clicks to trigger the context menu.
So it seems likely this has something to do with things intercepting / blocking / redirecting clicks and letting the GtkTreeView get confused about its mouse grabs. It's plausible that gtk_menu_detach could have this effect, indirectly. Or maybe it has something to do with MD forcing focus to a different pad's treeview when the command in the context menu is run.
Workaround has been pushed to master.
For the record, a reproducible case of this has been reported on X11,
and fixed in gtk-2-24: https://bugzilla.gnome.org/show_bug.cgi?id=675835