Bug 546 - [GTK] Clicking on disclosure triangle in treeview doesn't work
Summary: [GTK] Clicking on disclosure triangle in treeview doesn't work
Status: VERIFIED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.8 Alpha 2
Hardware: PC Mac OS
: High major
Target Milestone: ---
Assignee: Bugzilla
URL:
: 313 1071 1083 1492 1887 2003 3549 4407 ()
Depends on:
Blocks: 313 1371 4388
  Show dependency tree
 
Reported: 2011-08-30 14:18 UTC by Nat Friedman
Modified: 2013-06-19 09:38 UTC (History)
14 users (show)

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


Attachments
Patch that fixes the issue described in comment 6 (3.79 KB, patch)
2011-09-09 05:45 UTC, Kristian Rietveld (inactive)
Details
This patch fixes case 2 from comment 18 (967 bytes, patch)
2011-10-08 05:37 UTC, Kristian Rietveld (inactive)
Details


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:
VERIFIED FIXED

Description Nat Friedman 2011-08-30 14:18:41 UTC
http://screencast.com/t/TuFZr4KA
Comment 1 Mikayla Hutchinson [MSFT] 2011-08-30 14:38:37 UTC
This is an issue that has been biting us for some time. GTK doesn't always release mouse grabs.
Comment 2 Michael Natterer 2011-09-02 03:22:22 UTC
I'm able to randomly reproduce this bug on vanilla HEAD of upstream gtk-2-24, using
only testtreeview and gtk-demo. Investigating.
Comment 3 Michael Natterer 2011-09-02 04:35:12 UTC
Do you guys have a way to *reliably* reproduce that? Ever since I started debugging it won't happen, truly a Heisenbug.
Comment 4 Michael Natterer 2011-09-02 06:00:53 UTC
This upstream issue seems related: https://bugzilla.gnome.org/show_bug.cgi?id=566963
Comment 5 Mikayla Hutchinson [MSFT] 2011-09-02 06:21:05 UTC
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.
Comment 6 Kristian Rietveld (inactive) 2011-09-09 03:05:33 UTC
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.

Investigating.
Comment 7 Kristian Rietveld (inactive) 2011-09-09 05:33:19 UTC
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.
Comment 8 Kristian Rietveld (inactive) 2011-09-09 05:45:54 UTC
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.
Comment 9 Kristian Rietveld (inactive) 2011-09-16 04:00:15 UTC
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.
Comment 10 Kristian Rietveld (inactive) 2011-09-16 05:44:46 UTC
From comment 4:
> This upstream issue seems related:
> https://bugzilla.gnome.org/show_bug.cgi?id=566963

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?
Comment 11 Mikayla Hutchinson [MSFT] 2011-09-16 06:00:29 UTC
I doubt it, MonoDevelop has its own C#-based docking library, and we don't see the problem on Linux or Windows.
Comment 12 Kristian Rietveld (inactive) 2011-09-16 06:01:45 UTC
Ok then they are definitely not related, thanks for confirming.  (The UI of the docking libraries really looks quite similar though :)
Comment 13 Mikayla Hutchinson [MSFT] 2011-09-27 09:47:37 UTC
*** Bug 1071 has been marked as a duplicate of this bug. ***
Comment 14 Mikayla Hutchinson [MSFT] 2011-09-27 10:15:52 UTC
The duplicate bug has a way to reproduce it.
Comment 15 Nat Friedman 2011-09-27 11:21:16 UTC
Not sure this is exactly the same bug, because in the case of 1071, keyboard navigation doesn't work either.
Comment 16 Alan McGovern 2011-09-29 05:30:29 UTC
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.
Comment 17 Atin 2011-10-05 14:04:10 UTC
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.
Comment 18 Kristian Rietveld (inactive) 2011-10-07 02:28:33 UTC
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.
Comment 19 Kristian Rietveld (inactive) 2011-10-08 05:37:14 UTC
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.
Comment 20 Lluis Sanchez 2011-10-14 11:03:41 UTC
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.
Comment 21 Nat Friedman 2011-10-14 11:10:39 UTC
Unfortunately that repro doesn't work for me.
Comment 22 Kristian Rietveld (inactive) 2011-10-22 13:54:51 UTC
> 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.
Comment 23 Kristian Rietveld (inactive) 2011-11-06 03:41:22 UTC
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).
Comment 24 Kristian Rietveld (inactive) 2011-11-06 03:42:28 UTC
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?
Comment 25 Mikayla Hutchinson [MSFT] 2011-11-07 10:06:04 UTC
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.
Comment 26 Mikayla Hutchinson [MSFT] 2011-11-07 10:52:01 UTC
This appears to fix #1754.
Comment 27 Lluis Sanchez 2011-11-15 15:15:31 UTC
*** Bug 2003 has been marked as a duplicate of this bug. ***
Comment 28 Joseph Hill 2011-11-16 14:31:10 UTC
*** Bug 313 has been marked as a duplicate of this bug. ***
Comment 29 Mikayla Hutchinson [MSFT] 2011-11-22 15:20:29 UTC
*** Bug 1492 has been marked as a duplicate of this bug. ***
Comment 30 Mikayla Hutchinson [MSFT] 2011-11-22 15:27:28 UTC
*** Bug 1887 has been marked as a duplicate of this bug. ***
Comment 31 Jeffrey Stedfast 2011-12-19 16:06:16 UTC
*** Bug 1083 has been marked as a duplicate of this bug. ***
Comment 32 Mikayla Hutchinson [MSFT] 2012-01-03 14:40:03 UTC
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.
Comment 33 Mikayla Hutchinson [MSFT] 2012-02-21 15:38:44 UTC
*** Bug 3549 has been marked as a duplicate of this bug. ***
Comment 34 Eric Beisecker 2012-04-12 11:50:51 UTC
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.

Screencast: http://screencast.com/t/pR9I5SGi

Versions

MonoDevelop 2.9.4
Runtime:
	Mono 2.10.9 (tarball Tue Mar 20 15:31:37 EDT 2012)
	GTK 2.24.10
	GTK# (2.12.0.0)
Comment 35 Mikayla Hutchinson [MSFT] 2012-04-12 17:58:15 UTC
*** Bug 4407 has been marked as a duplicate of this bug. ***
Comment 36 Jeffrey Stedfast 2012-04-12 18:09:44 UTC
I'm getting this a lot recently as well, typically in the WatchPad
Comment 37 Chris Hardy [MSFT] 2012-04-12 18:21:20 UTC
I'm seeing too on both 2.9.4 and 2.9.5: http://screencast.com/t/WpjTmZgwkX9


MonoDevelop 2.9.5
Installation UUID: bfe4d389-101c-473e-bbcd-d2e0678bb8bb
Runtime:
	Mono 2.10.9 (tarball Tue Mar 20 15:31:37 EDT 2012)
	GTK 2.24.10
	GTK# (2.12.0.0)
Apple Developer Tools:
	 Xcode 4.3.2 (1177)
	 Build 4E2002
Mono for Android: 4.1.0.88858872
Monotouch: 5.3.2
Build information:
	Release ID: 20905000
	Git revision: 688e551a68f688fc36da48aae3d636f2b342b247-dirty
	Build date: 2012-04-12 17:52:45+0000
	Xamarin addins: 3b20fe54e002c6fdf3da8b1033a9e3e304c758b2
Operating System:
	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
Comment 38 Mikayla Hutchinson [MSFT] 2012-04-12 18:56:18 UTC
The latest issue reported by Eric might be a dup of 4388.
Comment 39 Mikayla Hutchinson [MSFT] 2012-04-12 19:01:11 UTC
Also wondering whether we should mark bug 3997 as a dup of this.
Comment 40 Mikayla Hutchinson [MSFT] 2012-04-12 19:28:59 UTC
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.
Comment 41 Kristian Rietveld (inactive) 2012-04-22 05:04:41 UTC
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?
Comment 42 Mikayla Hutchinson [MSFT] 2012-04-23 08:02:05 UTC
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.
Comment 43 Mohit Kheterpal 2013-06-19 09:38:08 UTC
Today we have checked this issue on following builds :

XS 4.0.9 (build 3)
MT 6.3.6.76
Mono 3.0.11

Now we are able to expand and close solution tree.

Hence closing this issue. Changing its status to verified.