GNOME Bugzilla – Bug 735755
[regression] 3.14: Direct draw to GtkLayout's bin_window not working when adjustments are not at position 0
Last modified: 2014-10-08 15:28:36 UTC
Created attachment 284944 [details] sshot When composing new message in the text editor part of the window, cursor ( | ) is mostly missing and it is very hard to navigate, if the message is longer and cannot fit into current window, and you "place" the cursor somewhere on the top scroll message down, it appears on top elements of the window, panels, buttons, ... and blinks, as shown on the screenshot it is over drop_down menu I'm not sure which component can affect this so I put some which can be related. evolution-ews-3.12.5-2.fc21.x86_64 evolution-3.12.5-2.fc21.x86_64 evolution-help-3.12.5-2.fc21.noarch evolution-data-server-3.12.5-3.fc21.x86_64 gtkmm24-2.24.4-4.fc21.x86_64 gtk3-3.13.7-2.fc21.x86_64 gtksourceview3-3.13.90-1.fc21.x86_64 gtkspell3-3.0.6-4.fc21.x86_64 gtk-vnc2-0.5.3-4.fc21.x86_64 gtkhtml3-4.8.4-2.fc21.x86_64 gtk2-2.24.24-2.fc21.x86_64 gtkmm30-3.13.7-1.fc21.x86_64 webkitgtk3-2.4.5-2.fc21.x86_64 webkitgtk4-2.5.3-6.fc21.x86_64
Confirmed in f21 branched with similar package set, this is pretty annoying.
For me this is partially fixed in latest 3.14.0 (big update) in fedora. Now cursor is mostly present when I type, but when there is a lot of text (or just looks like that) and I move cursor up/down it disappears sometimes, and when it disappears and you start typing it sometimes start working again (cursor blinks while idle ...), sometimes not.
as with bitlord, this seems a bit better in recent builds, but not fully fixed. It's hard to spot precisely what triggers it, though. I'll have to try and keep an eye out for it.
This is not likely a bug in Evolution's code. It would be helpful to state your gtk3 package version in these comments, and maybe downgrade gtk3 to help isolate where the bug was introduced. Note the composer in 3.12 is still based on gtkhtml, not webkit.
gtk3-3.14.1-1.fc21.x86_64 at present.
Packages installed here are gtk3-3.14.1-1.fc21.x86_64 gtkhtml3-4.8.4-2.fc21.x86_64
Created attachment 287965 [details] test application This test application proves this not being evolution's issue, but GTK+'s. The application doesn't do anything special, it creates a window, puts into it a scrollable area and inside it a GtkLayout. Then it draws directly to the layout's bin_window, just the same as the GtkHTML's editor does, except it doesn't draw a cursor, but a line from the left-top corner to the right-bottom corner, divided into 15 segments which are constantly redrawn. The application opens with shifted scrollbars, which exhibits the issue immediately, because the line is not drawn from the left-top corner, but with the offset close (or the same) to the scrollbar positions. Moving scrollbars to the right-bottom corner (without changing the default window size) will never draw the line in that part of the view. This behaviour is new in gtk+ 3.14. I am able to reproduce it with 3.14.1. The gtk+ 3.12.2 works as expected.
A little follow up: 3.13.2 works fine, 3.13.3 is broken. The NEWS line: > ... > * Deprecations: > ... > - gdk_window_flush, drawing outside of begin/end paint looks suspicious/related, because this is what the application does, it draws outside of the begin/end paint, but doesn't use gdk_window_flush() at all.
can you try if it works again in the current gtk-3-14 branch, please ?
gtk+ checkout at branch gtk-3-14 and commit 693b568 works properly. It might be 3.14.2 yesterday release, if I read the commit history properly.
yes, it is included there. thanks for testing!