Bug#988951: marked as done (regression: focus_path on last items no longer works properly)
Your message dated Mon, 24 May 2021 02:33:27 +0000
with message-id <E1ll0PHfirstname.lastname@example.org>
and subject line Bug#988951: fixed in cdebconf 0.259
has caused the Debian Bug report #988951,
regarding regression: focus_path on last items no longer works properly
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact email@example.com
Debian Bug Tracking System
Contact firstname.lastname@example.org with problems
--- Begin Message ---
X-Debbugs-Cc: Simon McVittie <email@example.com>
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
- 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 (firstname.lastname@example.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
--- End Message ---
--- Begin Message ---
Done: Cyril Brulebois <email@example.com>
We believe that the bug you reported is fixed in the latest version of
cdebconf, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to firstname.lastname@example.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
Cyril Brulebois <email@example.com> (supplier of updated cdebconf package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing firstname.lastname@example.org)
-----BEGIN PGP SIGNED MESSAGE-----
Date: Mon, 24 May 2021 04:18:08 +0200
Maintainer: Debian Install System Team <email@example.com>
Changed-By: Cyril Brulebois <firstname.lastname@example.org>
cdebconf (0.259) unstable; urgency=medium
[ Simon McVittie ]
* Revert “Postpone adding text to GtkTextView until GTK has done initial
layout” change from the previous version, as it triggers a regression
regarding the entry getting the focus (Closes: #988951).
* Work around #988787 in a different way, intercepting the size-request
event and adjusting the requested width to a minimum of 300 pixels.
This seems sufficient to avoid the infinite loop in GTK (#988786).
[ Cyril Brulebois ]
* Huge thanks to Simon McVittie for the incredible support! (again)
* Normal installation and rescue tests have been run in many languages,
and the trivial hangs that both 0.258 and 0.259 aim at fixing could no
longer be produced. As usual, bug reports are more than welcome if
some hang is still hidden somewhere!
8fe9b9005864bd7554266879854a1c52946f62a4 2746 cdebconf_0.259.dsc
b0e89a6e21efd441b46a40d29c24711123d45da0 279744 cdebconf_0.259.tar.xz
3dd8e40b95d30e1714e2401d5611b54fa9b64ac7 11485 cdebconf_0.259_source.buildinfo
4cae3a15db81588e719f2a9989d121e30f2c338e06a4e2e3150295989ca1c4af 2746 cdebconf_0.259.dsc
7fa2951944fe97833ec63384dc7c19bc11ee10ce2bca0731592ff5029b60236a 279744 cdebconf_0.259.tar.xz
c498a8a6a3f90c1702329142b47f72bf2b52349535f83b06faa9d6690aeca41c 11485 cdebconf_0.259_source.buildinfo
62dfebdaa84b85d475da9a1812a17712 2746 utils optional cdebconf_0.259.dsc
de09874562093b9c9268cd0a0f8fb3ea 279744 utils optional cdebconf_0.259.tar.xz
caeb8d1e93c5ae15461ebe4d2bcd8713 11485 utils optional cdebconf_0.259_source.buildinfo
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
--- End Message ---