GNOME Bugzilla – Bug 78513
Scrolling by keeping Page Up/Down down is broken
Last modified: 2011-02-04 16:16:07 UTC
In a large document, when you scroll up or down by holding down the Page Up/Down key, the GtkTextView sometimes get's "locked" (it seems to scroll down and then up and down again etc). Even after releasing the key, the behavior continues for several seconds. Happened on both my laptop and on my desktop. GTK+ version is cvs head from a couple of days ago.
*** Bug 76975 has been marked as a duplicate of this bug. ***
Move GtkTextView 2.0.4 bugs to 2.0.5
This happens because of incorrectly flushing a pending scroll when already scrolling beyond. The code path goes like this: - user hits page key -> gtk_text_view_scroll_pages - set_adjustment_clamped - scrolling validation codepath - gtk_text_view_scroll_mark_onscreen -> scroll is queued Now if the user queues a page key press *before* the scroll is flushed in the idle handler: - gtk_text_view_scroll_pages - set_adjustment_clamped - scrolling validation codepath now begins: - gtk_text_view_value_changed - gdk_window_scroll - gtk_text_view_validate_online - process updates - expose handler - flush_first_validate - flush_scroll -> scrolls back, but doesn't reenter the scroll validation codepath since value_changed is not recursive - paint - gtk_text_view_scroll_mark_onscreen -> new scroll is queued Worst case: if *between* this last process updates and the expose event the onscreen information is invalidated due to the layout emitting the "invalidated" signal (e.g. an expose user signal handler which modifies the buffer), since flush_scroll returns true, onscreen is not revalidated, and the final assertion in flush_first_validate fails. This is because this code assumes flush_scroll will produce a revalidation, which doesn't happen because "value_changed" signal is not recursive. Observations: even if the buffer is fully validated, I don't know why the layout sometimes emits the "invalidated" signal, thus triggering this behavior. Is this expected? Proposed solution (patch attached): - Remove the queued scroll before changing the adjustment in scroll_pages and scroll_hpages. - In flush_first_validate also validate onscreen lines if onscreen_validated is FALSE (this is not necessary but makes the code more robust imho)
Created attachment 9725 [details] [review] Proposed solution
You are a brave man, and I owe you a beer, for jumping into this code. The analysis/solution look promising. I'll plan to look at it tonight, or as soon as possible. Please hassle me if I don't.
*** Bug 88957 has been marked as a duplicate of this bug. ***
Created attachment 10039 [details] [review] patch for 2.0.x branch
I applied the patch to HEAD, with a small formatting change. The attached patch is for stable. Not applied to stable yet since Owen is working on 2.0.6.
I don't understand the logic. I'm not distchecking currently...
a) I don't know when you are distchecking and b) I haven't really tested the patch much.
*** Bug 93522 has been marked as a duplicate of this bug. ***
Moving bugs from older 2.0.x milestones to 2.0.10.
*** Bug 82086 has been marked as a duplicate of this bug. ***
There is a patch on this bug, can it be applied to stable branch?
Making all 'high' textview bugs 2.2.0 as per havoc's request.
This was applied to the stable branch in August, actually.
*** Bug 103261 has been marked as a duplicate of this bug. ***
*** Bug 105587 has been marked as a duplicate of this bug. ***
*** Bug 106198 has been marked as a duplicate of this bug. ***
Reopening because the bug is back. [paolo@elihost tests]$ pkg-config --modversion gtk+-2.0 2.2.4
This bug regressed with Gtk+ 2.2.2 (2.2.1 was OK, and 2.2.2, 2.2.3, 2.2.4 are not). Arno
*** Bug 75267 has been marked as a duplicate of this bug. ***
Since it's a problem with gtk+-2.2.x for x>1 (according to the previous comments), I'll update the version and keywords.
More info: the culprit is the following change: revision 1.216.2.12 date: 2003/06/05 22:59:23; author: owen; state: Exp; lines: +15 -20 Thu Jun 5 16:52:54 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtktextview.[ch]: Never scroll on focus in (#81893, Patch from Paolo Maggi) * gtk/gtktextview.c (gtk_text_view_scroll_[h]pages): Scroll to the current cursor location before handling the action, in case the user just tabbed in and the cursor is offscreen. More specifically, the last part: remove the call to gtk_text_view_scroll_mark_onscreen in gtk_text_view_Scroll_[h]pages fixes this bug. Arno
*** Bug 124822 has been marked as a duplicate of this bug. ***
*** Bug 128173 has been marked as a duplicate of this bug. ***
Note that this bug probably shouldn't have been reopened, since it's almost certainly just a different bug with the same symptom.
The current bug, as I understand it is: * gtk_text_view_scroll_mark_onscreen(), called twice from gtk_text_view_scroll_[h]pages() queues a scroll if anything in the view is invalid * the code in scroll_[h]pages assumes that scrolls take effect immediately. * But moving the cursor invalidates both the new and old paragraphs, so for repeated fast scrolling, we are always queueing scrolls that take effect later and yank the position of the window back. One thing that could help, though it woudl a little complex to implement would be the ability to say "scroll this mark onscreen wheever this mark is when the queued scroll happens" - right now scroll_mark_onscreen creates a temporary mark at the current location of the insertion cursor mark, which is absolutely the wrong thing, we just want to use the insertion cursor mark.
For test purposes I ifdefed away the creation of the temp mark and just used the mark given to scroll_mark_onscreen(). It doesn't help at all.
*** Bug 137803 has been marked as a duplicate of this bug. ***
Created attachment 26817 [details] [review] patch to avoid queuing too many scrolls Here is a possible fix.
*** Bug 143122 has been marked as a duplicate of this bug. ***