GNOME Bugzilla – Bug 791931
Moving selection down causes too much scrolling
Last modified: 2017-12-25 22:31:52 UTC
When the active cell is in the first row, pressing the up cursor key scrolls up by one row, just enough to reveal the new active cell. When the active cell is on the last row, pressing the down cursor key scrolls down by an entire page, leaving the new active cell on the first row. I would expect that pressing the down arrow would scroll down by one row, leaving the new active cell on the bottom row, similarly to how it works when pressing up arrow. This happens mainly when “Snap Columns to Powers of 2” is off. The problem is probably difficult to reproduce, since, as discussed below, it seems to require the window to be just wide enough that the number of columns depends on whether there is a vertical scrollbar or not. With the Xubuntu 17.04 default theme, I got this bug with a window width of 768 pixels. Debugging reveals that gucharmap_chartable_size_allocate is called at least three times when focusing the window or scrolling with the cursor keys, if the bug is active. The second call has a slightly wider allocation, and the first and third calls have the same allocation. I believe the second call is a trial allocation without room for a vertical scrollbar, to see whether a scrollbar is needed. If the number of columns (or rows) changes with the new call to gucharmap_chartable_size_allocate, it sets priv->page_first_cell such that the new active cell is in the top row. If the computed number of columns changes between the first and second calls to gucharmap_chartable_size_allocate, then the scrolled window will unexpectedly warp to the point where the active cell is in the top row. There is a comment: /* Need to recalculate the first cell, see bug #517188 */ before the recalculation of priv->page_first_cell. I don’t know how to solve this, because the multiple calls to gucharmap_chartable_size_allocate seem to be by design (of GtkScrolledWindow), and there is no obvious way to update priv->page_first_cell so that it will have the same value on the third call to gucharmap_chartable_size_allocate that it did to begin with. I found this bug while investigating #791715.
The only way I can think of to solve this is to set the vertical scrolling policy of the character table to GTK_POLICY_ALWAYS on gucharmap-charmap.c:1262 so that we don’t do size_allocate without the scrollbar. This also seems to fix bug #791715 and I don’t think it’s that ugly
I've made this change now on git master; thanks for the investigation. This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.