Bug 4388 - [regression] unit test result nodes sometimes can't be expanded
Summary: [regression] unit test result nodes sometimes can't be expanded
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: Trunk
Hardware: PC Linux
: High normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on: 546
Blocks:
  Show dependency tree
 
Reported: 2012-04-10 21:20 UTC by Csaba Halász
Modified: 2012-05-31 05:06 UTC (History)
3 users (show)

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

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:
Status:
RESOLVED FIXED

Description Csaba Halász 2012-04-10 21:20:52 UTC
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
commit 362edd8fc73da7e2e30906897c4831065b04262f
Author: Michael Hutchinson <m.j.hutchinson@gmail.com>
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)
Comment 1 Mike Krüger 2012-04-11 01:33:00 UTC
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.
Comment 2 Csaba Halász 2012-04-11 08:32:40 UTC
If I revert the commit I mentioned in the first comment, everything seems to work fine again.
Comment 3 Mikayla Hutchinson [MSFT] 2012-04-12 18:41:00 UTC
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.
Comment 4 Mikayla Hutchinson [MSFT] 2012-04-12 18:52:12 UTC
On second thoughts, I think we need to detach it to prevent a leak...
Comment 5 Mikayla Hutchinson [MSFT] 2012-04-12 18:55:46 UTC
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.
Comment 6 Mikayla Hutchinson [MSFT] 2012-04-12 19:16:17 UTC
Confirmed it will leak unless we detach it.
Comment 7 Mikayla Hutchinson [MSFT] 2012-04-12 20:36:59 UTC
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.
Comment 8 Mikayla Hutchinson [MSFT] 2012-04-23 07:57:38 UTC
Workaround has been pushed to master.
Comment 9 Michael Natterer 2012-05-31 05:06:29 UTC
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