GNOME Bugzilla – Bug 761676
Touch text selection handles don't move on scroll
Last modified: 2016-02-24 17:37:20 UTC
Created attachment 320578 [details] picture of the bug If you have, say, a listbox, select some text and then scroll it (all via the touchscreen). In the app I used I had ListBox > ScrolledWindow > TextView.
A small testcase would be helpful
Created attachment 321791 [details] testcase
Hmm, text handles currently hook up to the first GtkScrollable found. In this case that's the per-row GtkTextView itself, not the GtkViewport containing the GtkListBox. I guess we could connect to scrollables up the hierarchy, but maintaining the scrollable and adjustment signals will be kind of a pain... FWIW, if multiline is not needed, GtkEntry won't have this problem.
Which I see it is in the photo attached in comment #0... nevermind
could we skip the scrollable if it isn't actually used for scrolling ?
(In reply to Matthias Clasen from comment #5) > could we skip the scrollable if it isn't actually used for scrolling ? Right, I guess we want the scrollable that's actually a child of a GtkScrolledWindow, we can look up for this indeed.
Created attachment 322256 [details] [review] GtkTextHandle: Look up for the first child of a scrolled window found Text handles use to connect to the first GtkScrollable up the hierarchy so they can be repositioned when scrolling. It makes more sense to look up the first child of a GtkScrolledWindow, it must be an scrollable too, and will be the scrollable that can actually change the position of the text handles.
Review of attachment 322256 [details] [review]: ::: gtk/gtktexthandle.c @@ +558,3 @@ + + return gtk_bin_get_child (GTK_BIN (scrolled_window)); +} I guess you could construct contrived examples where more than one scrolledwindow in the ancestry could make the handles move, but lets just ignore that for the time being.
Attachment 322256 [details] pushed as 60d7f43 - GtkTextHandle: Look up for the first child of a scrolled window found