Currently static backgrounds are not handled and lead to ugly drawing. This patch is going to fix it by forking GtkLayout. Forking was one of three strategies tried and is IMHO the best.
Created attachment 15517 [details] Fix static backgrounds
Is copying this big hunk of Gtk code really the only way to do this? Maybe it would work to just connect "value_changed" signal handlers from outside the class? Or maybe we can subclass GtkLayout? Cut & pasting the whole thing seems like a pretty extreme approach.
The are two changes to GtkLayout where I think only one is important. Before calling gdk_window_move we need to unmap the GtkWidget and afterwards map it again. The method/closure connected to the value_changed signal of adjustments is private, so subclassing is not possible. The approaches I saw where: -I don't know if it is possible but disconnect the gtk_layout_value_changed closure and implement this inside webkit. The downside was that the secret of moving the window is shared between Gtk+ and WebKit and I assumed this will be error prone. -One could try to connect the value_changed signal twice. The first closure would unmap the GtkWidget in case of static backgrounds and the other one would map it again. I was not certain if I can gurantee to always be called before the GtkLayout closure. I think one shouldn't share secrets and I'm not certain the second approach will work, this is why I decided to copy/fork GtkLayout. I need some clarification regarding Frame, FrameView and FrameTree interaction so we might end up with a completely different approach (will send an email).
Comment on attachment 15517 [details] Fix static backgrounds We will move away from GtkLayout, including a forked copy of it doesn't make sense.
Add the Gtk keyword, even to the curl bugs.
#14729 has a ScrollView 'rewrite' fixing this issue as well.