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

Bug#988951: regression: focus_path on last items no longer works properly

Package: cdebconf-gtk-udeb
Version: 0.258
Severity: important
X-Debbugs-Cc: Simon McVittie <smcv@debian.org>


The 0.258 update is *very* important for us since it makes extra sure
(together with libgtk2.0-0-udeb 2.24.33-2) we don't run into relayout
loops meaning hangs from a user point of view.

Yes, it comes at a price: focussing on the last items of a GtkTreeView
no longer works correctly.

There might be simpler (shorter) ways to trigger this but the following
is robust:

 - Initially detected while testing an encrypted LVM install in Swedish
   (confirming all hangs go away), when reaching the partition layout
   confirmation dialog, the selected entry is the last one in the list,
   but the selection isn't seen. One might wonder where the focus is,
   why no entry was selected, etc. Since that can happen in various
   places, I think users might get confused. That should not be specific
   to Swedish, it just happens to be the first occurrence I noticed.

 - Slightly shorter (`kvm -m 1G -cdrom mini.iso`, no disk layout or even
   disk required), pick a language like French and all default choices,
   until the mirror country selection, pick the very last one
   (États-Unis), and on the mirror host selection, pick the very last
   one again (the actual hostname doesn't matter). Now, on the next
   dialog, hit “Revenir en arrière” (Back), and see the selected
   hostname isn't focussed. Another step back shows the selected country
   isn't focussed either. That should happen with other languages as
   well, using French has the main advantage for me to get the
   appropriate keyboard layout automatically plus get two “back” steps
   that exhibit the problem (other countries might not have a mirror
   list as big as the US one).

With both gtk+2.0 and cdebconf being uploaded recently, I've made sure
to determine what triggers this:
 - bulleye: OK
 - unstable: KO
 - bullseye + gtk2.0: OK
 - bullseye + cdebconf: KO

My first hunch was that the focus_path callback (one-shot call, it
disables itself once it has triggered gtk_tree_view_scroll_to_cell on
the first expose event) happens before the set_text_in_idle one, and
that's indeed correct. I suppose we have a slightly taller widget at
first, we scroll down to the bottom; then when set_text_in_idle happens,
the widget is resized slightly smaller, the position is not correct
anymore (it's no longer “full-bottom” but a little higher as seen in the
scrollbar), and the selected line gets out of sight.

I've tried various things like having the focus_path happens in a
“_later” indirection using the same kind of logic as Simon introduced
for setting the text (with a different priority), but that would happen
waaay before set_text_in_idle anyway.

I've also tried to implement a “double-tap” approach, letting the
callback be called twice, so that we would focus first, let the text be
set and get a new expose event, and re-focus. But it seems the amount of
events we need to reach this point is not constant (I didn't conduct a
real study but it seems one might need up to 4-5 such events).

Next on my list of things to try was adding a pointer to the frontend
object (and its `data` member) so that we could keep the callback alive
until set_text_in_idle has done its job. I thought it might need some
mutex or locking around a counter of pending set_text calls and I
haven't touched that yet. And today, the following rang a bell… :)

I'm happy to be told whether the vague idea above looks like a
workaround that could or even should work before diving a little more
into it, and/or to be suggested better ideas!

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Reply to: