Re: Bug in ctree:resync_selection?

[Owen Taylor <otaylor redhat com>]

Owen Taylor <otaylor@redhat.com> writes:

> David Helder <dhelder@umich.edu> writes:
> 
> > The problem can be reduced to double clicking a node in a ctree (and
> > probably a clist) and then pressing shift causes a seg fault in
> > resync_selection.
> > 
> > This is now gtk+ bug #5487 (http://bugs.gnome.org/db/54/5487.html).  
> > There is a small test case.
> 
> I've merged this bug with 2051 and 2677, which seem to be the same
> thing or closely related bugs.
> 
> Lars, do you think you'll have chance to look at these bugs 
> (It looks like I pointed out 2051 to you some time ago), or
> alternatively, write some documentation about how the selection
> code in CList/CTree is supposed to work? 

OK, I'm looked at this some more to see if I could figure out why
the CList was getting into an inconsistent state in the first place.

The culprit seems to be the code in gtk_clist_button_press:

=====
	  if (event->type == GDK_BUTTON_PRESS)
	    {
                [...]
	    }
	  else
	    {
	      clist->click_cell.row = -1;
	      clist->click_cell.column = -1;

	      clist->drag_button = 0;
	      remove_grab (clist);
	    }
======

the else clause here is harmful, because we get a seequence like:

  BUTTON_PRESS
  2BUTTON_PRESS
  BUTTON_RELEASE

and clist->drag_button is reset to zero in response to 2BUTTON_PRESS,
so the necessary cleanup isn't done in BUTTON_RELEASE.

However, I have no idea why this code was put in there in the first
place, and doing a thorough check of clist/ctree functionality after
removing it isn't really practical so I'll just put the sanity checks
into the resync_selection and a FIXME here.

Regards,
                                        Owen