After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735755 - [regression] 3.14: Direct draw to GtkLayout's bin_window not working when adjustments are not at position 0
[regression] 3.14: Direct draw to GtkLayout's bin_window not working when adj...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-08-31 17:19 UTC by Branko Grubic (bitlord)
Modified: 2014-10-08 15:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sshot (6.79 KB, image/png)
2014-08-31 17:19 UTC, Branko Grubic (bitlord)
Details
test application (2.72 KB, text/plain)
2014-10-07 14:27 UTC, Milan Crha
Details

Description Branko Grubic (bitlord) 2014-08-31 17:19:09 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
Comment 1 Adam Williamson 2014-09-17 18:55:28 UTC
Confirmed in f21 branched with similar package set, this is pretty annoying.
Comment 2 Branko Grubic (bitlord) 2014-09-28 13:27:44 UTC
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.
Comment 3 Adam Williamson 2014-10-03 16:38:09 UTC
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.
Comment 4 Matthew Barnes 2014-10-03 17:11:10 UTC
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.
Comment 5 Adam Williamson 2014-10-03 17:14:51 UTC
gtk3-3.14.1-1.fc21.x86_64 at present.
Comment 6 Branko Grubic (bitlord) 2014-10-03 17:15:59 UTC
Packages installed here are
gtk3-3.14.1-1.fc21.x86_64
gtkhtml3-4.8.4-2.fc21.x86_64
Comment 7 Milan Crha 2014-10-07 14:27:48 UTC
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.
Comment 8 Milan Crha 2014-10-07 14:59:02 UTC
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.
Comment 9 Matthias Clasen 2014-10-07 16:38:02 UTC
can you try if it works again in the current gtk-3-14 branch, please ?
Comment 10 Milan Crha 2014-10-08 08:56:37 UTC
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.
Comment 11 Matthias Clasen 2014-10-08 15:28:36 UTC
yes, it is included there. thanks for testing!