GtkCList sending select_row on non-existent row

I traced a segfault in Nautilus
( down to some fishy
GtkClist behavior, which I believe was introduced fairly recently, since
this Nautilus bug seems like it would have been noticed long ago

The fishy behavior is that when the last row is removed, real_remove_row
still emits a SELECT_ROW signal, with the selected row set to 0. But of
course there is no row 0. I had an assert in Nautilus that failed a
parameter check due to this mismatch, hence the crash. I can make
Nautilus not crash here, but I'm not sure what to do about GtkCList.

The code that's sending the SELECT_ROW signal is this, with a little
preceding code also quoted (This is in the stable branch, gtk-1-2):

  /*if (clist->focus_row >=0 &&
      (row <= clist->focus_row || clist->focus_row >= clist->rows))

  if (row < ROW_FROM_YPIXEL (clist, 0))
    clist->voffset += clist->row_height + CELL_SPACING;

  if (clist->selection_mode == GTK_SELECTION_BROWSE && !clist->selection
      clist->focus_row >= 0)
    gtk_signal_emit (GTK_OBJECT (clist), clist_signals[SELECT_ROW],
		     clist->focus_row, -1, NULL);

That commented-out hunk of code sure looks relevant, but it was
commented out long ago (November 1998). There's is no code in
real_remove_row to change the focus row, so if it was the only row
before (0), it will still be 0 here, and the signal will be sent with 0,
which is wrong since row 0 does not exist.

Am I right to think that sending a select_row signal on a non-existent
row is a GtkCList bug? Or should I just make Nautilus robust to this and
live with it?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]