Thanks for a bug report. it seems the theme you use got something wrong, or simply they changed it again. This is a never ending story of no reliability on themes, which is quite sad.

I'm moving this to gtk+, because there are more things broken, like colors in the tooltip, which are fully in hands of the gtk+.

'The theme I'm using' is the stock GTK+ theme, to be clear.

I'm seeing the same thing. Highlighting doesn't work in some applications like nautilus (white highlight on white background when some folders/files are selected), evolution (same as in the description), firefox (some text get ugly black highlight but some get white, the not visible one, for example I can't see what I'm highlighting here in this comment field) and probably some other applications.

I'm using Fedora Rawhide with gtk3-3.19.4-1.fc24.x86_64.

Milan Crha, gtk+ css is seeing huge improvements hence please tollerate some breakage.

I think I nailed this specific issue in master with "21a2fce8ba2a48fe3781e7a1f02b33e3a7bfd9ac" but the treeview is a bad beast not to mention treeview derived widgets, so guys please test this and report possible other oversights, leaving open waiting for your feedback.

Lapo. I believe this is about *text*view not *tree*view, at least in the evolution case.

Correct, you see this when drag-selecting text in the message display pane or composer in Evolution for e.g.

Matthias, yeah this is about what was styled with '.view" in the past in general, some derived widgets don't have a css node name, so I added back .view selector to relevant styling, a selector wrt textview text was missing, should be fixed now. Please test.

Message display uses webkitgtk+. Evolution sets its selected/not selected colors based on colors being returned by the theme. I do not think evolution would be able to get raw CSS and pass it to webkit to draw the background/colors properly (when the theme has set an image for it, but no color) and it's not possible to draw pages with webkit using 'paint' functions from GTK. The problem then is when the theme doesn't provide the colors, but only images. Evolution fights with this unreliability of background colors in theme since the CSS become reality in GTK+.

I can be wrong in some of my observations, especially with the development version of the GTK+.

In epiphany with a webkit build of 2 days ago selections are visible here. In evolution EHTMLEditorView selections are still white on white, I'm pretty sure it isn't a theme bug anyway, since a very broad selectors doesn't works there (you can try with 'selection, *:selecter { color: red; }' in the inspector), so I guess there some bad interactions with that widget and latest gtk+, the terminal output here is full of 
'(evolution:29827): Gtk-WARNING **: State 1024 for EHTMLEditorView 0x55f9878cad60 doesn't match state 192 set via gtk_style_context_set_state ()' 
and similar error which look pretty "suspicious" to me.

(In reply to Lapo Calamandrei from comment #10)
> '(evolution:29827): Gtk-WARNING **: State 1024 for EHTMLEditorView
> 0x55f9878cad60 doesn't match state 192 set via gtk_style_context_set_state
> ()' and similar error which look pretty "suspicious" to me.

Ehm, does the runtime warning mean that one cannot ask for a proper color of a different state than the style was set initially? I'd like to know where that comes from, to not blame wrong API.

Here's a pointer where the evolution looks for the colors used in the message preview. It uses gtk_style_context_lookup_color() there:
https://git.gnome.org/browse/evolution/tree/em-format/e-mail-formatter.c#n495

Those 'state X does not match state Y' warnings are a plague with GTK+ 3.19, just about *everything* seems to be generating them. My journals are stuffed with them.

(In reply to Adam Williamson from comment #12)
> Those 'state X does not match state Y' warnings are a plague with GTK+ 3.19,
> just about *everything* seems to be generating them. My journals are stuffed
> with them.

There are however, not generated by this code:

https://git.gnome.org/browse/evolution/tree/em-format/e-mail-formatter.c#n495

because gtk_style_context_lookup_color does not take a state argument and color resolution does not depend on the state at all.

(In reply to Milan Crha from comment #11)
> (In reply to Lapo Calamandrei from comment #10)
> > '(evolution:29827): Gtk-WARNING **: State 1024 for EHTMLEditorView
> > 0x55f9878cad60 doesn't match state 192 set via gtk_style_context_set_state
> > ()' and similar error which look pretty "suspicious" to me.
> 
> Ehm, does the runtime warning mean that one cannot ask for a proper color of
> a different state than the style was set initially? I'd like to know where
> that comes from, to not blame wrong API.

The warning means that doing things like this:

/* widget is in, say NORMAL state */
context = gtk_widget_get_style_context (widget);
gtk_style_context_get_color (context, GTK_STATE_SELECTED, &color);

is broken in the sense that it causes an invalidation out of the drawing code (leading to new drawing causes another invalidation...)

You can do the following to avoid the problem (and the warning):

/* widget is in, say NORMAL state */
context = gtk_widget_get_style_context (widget);
gtk_style_context_save (context);
gtk_style_context_set_state (context, GTK_STATE_SELECTED);
gtk_style_context_get_color (context, gtk_style_context_get_state (context), &color);
gtk_style_context_restore (context);

(In reply to Matthias Clasen from comment #14)
> /* widget is in, say NORMAL state */
> context = gtk_widget_get_style_context (widget);
> gtk_style_context_save (context);
> gtk_style_context_set_state (context, GTK_STATE_SELECTED);
> gtk_style_context_get_color (context, gtk_style_context_get_state (context),
> &color);
> gtk_style_context_restore (context);

This just proves that the argument to the gtk_style_context_get_color() is useless. What should be done, instead of the runtime warning, is to do this save && restore call inside the function, when the states do not match.

Would it be that hard in gtk, that the API forces each single caller of the function to change one liner to 4 lines of the code?

Sadly, selection is still white-on-white in evolution with 3.19.7

I caught the first warning and it comes from
   gtk_style_context_get_background_color()
called by
   WebCode::RenderThemeGtk::initMediaColors()
Yes, it is from WebKitGTK3. Do not expect them to fix it, neither increase dependency on gtk3 (I cannot speak for them, but it would be a surprise to see it "fixed" in WebKit1, which is effectively dead upstream).

Also, for example MATE environment provides correct colors, while GNOME Shell doesn't. Both run on Fedora rawhide, with the same gtk3 (3.19.7-1),
evolution (3.19.4-2) and webkitgtk3 (2.4.9-6).

I see also wrong background colors above the message list and on the status bar, only when run under gnome-shell.

gnome-shell has nothing to do with this

time to get off your dead dependencies :-(

I just tried and running
   /usr/libexec/webkitgtk3/GtkLauncher
(it opens google.com, is part of webkitgtk3 in Fedora) shows three warnings from gtk GtkStyleContext and uses white background for selection in GNOME Shell. Thus this is not fully Evolution's issue, but is much deeper.

The /usr/bin/MiniBrowser (part of webkitgtk4-devel in Fedora) shows correct background of the selection in both desktop environments. It's using WebKit2.

I also realized that while we define some colors of the "page" based on the theme, the selected background is not one of them in the Mail view.

(In reply to Matthias Clasen from comment #18)
> gnome-shell has nothing to do with this

It can, if it uses different theme. Which it does here, as I just realized. gnome-tweak-tool says 'Adwaita' for all items on both GNOME Shell and MATE, though the MATE Appearance didn't have set Adwaita. When I change it to Adwaita there, the colors are broken as well.

(In reply to Matthias Clasen from comment #19)
> time to get off your dead dependencies :-(

It's not that simple in the evolution case, I'm sorry.

Isn't webkit1 gtk+2?

(In reply to Lapo Calamandrei from comment #21)
> Isn't webkit1 gtk+2?

No. WebKit1 is webkitgtk3, WebKit2 could be built as part of webkitgtk3, but it's the current and only version of webkitgtk4 (if I recall correctly the '3', respectively '4', in webkitgtkX name means API version, or something close to it).

Carlos, what (if anything) do you want to do about this?

mclasen:  mcatanzaro: is there any change of a bandaid fix for https://bugzilla.gnome.org/show_bug.cgi?id=757503 on the webkit side ?
bugbot:  Bug 757503: gtk+, major, Normal, ---, gtk-bugs, NEW , Selected text is white on white (invisible) - WebKit1 / GTK+ 3.19.7 & Adwaita
mcatanzaro:  mclasen: I would strongly prefer to leave it broken to encourage developers to upgrade their apps. But maybe KaL would want to do a 2.4.10 update. It's up to him.
mclasen:  evolution has been encouraged for quite a while now....still I hear it'll be 3.22 the earliest for them :-(
mcatanzaro:  mclasen: The problem is we have >130 unfixed security vulnerabilities in the 2.4 series and no intention of fixing them, doing another release gives developers the impression that it's acceptable to keep using it.
– mcrha has disconnected (Quit: That wasn't me)
mclasen:  how about a downstream patch then ?
mcatanzaro:  An email client that renders HTML but doesn't get security updates is not really a good thing....
mcatanzaro:  mclasen: We were discussing removing the package downstream and just not having any of the apps that depend on it (F25 timeframe)....
rishi:  Or sandbox evolution?
mclasen:  ok; that still leaves f24...
mcatanzaro:  Yeah, still leaves F24....

For GTK+ 3.20 compatibility in WebKitGTK+ 2.4, you would want to backport the following patches:

http://trac.webkit.org/changeset/194377
http://trac.webkit.org/changeset/194844
http://trac.webkit.org/changeset/194847
http://trac.webkit.org/changeset/194955
http://trac.webkit.org/changeset/195167

For 129 reasons why you should not do so, see:

http://webkitgtk.org/security/WSA-2015-0002.html

I didn't go back far enough. These three would come first, then the five above:

http://trac.webkit.org/changeset/190662
http://trac.webkit.org/changeset/192723
http://trac.webkit.org/changeset/193896

(In reply to Milan Crha from comment #20)
> It's not that simple in the evolution case, I'm sorry.

Can evolution fork what is needed from webkit1 into a minimal internal library and maintain it similar to what was done with gnomecanvas in the past?

(In reply to Michael Catanzaro from comment #23)
> mcatanzaro:  An email client that renders HTML but doesn't get security
> updates is not really a good thing....

I do not know what kind of security issues you are talking about. If it's about plugins and java script and similar, then evolution disables all but gtk+ plugins at its early start, the same as scripts [1].

> mcatanzaro:  mclasen: We were discussing removing the package downstream and
> just not having any of the apps that depend on it (F25 timeframe)....

I'm sorry, that sounds very selfish and bullying. You discuss that with whom? Do you know what manpower is available in each project you want to kick off and what resources can be dedicated for the webkit2 port (or finding other alternative) for all those projects? It doesn't seem to. It's an obvious regression in the Adwaita, still you are finding ways to drop some software which is useless for you, but which is used by real users. Ha! That's great (and selfish and bullying)! What's wrong with you?

Anyway, (I do not want to be rude, thus rather 'anyway') this bug report diverged significantly. My point of view on this: some change in Adwaita theme (or gtk+) caused a software which worked for years to fail. It was a recent change in a core library which is used by many applications. They can also be broken, even they were not before that change. What change it was or why it broke I do not know, I do not develop neither of these. It's only quite sad to see such regressions, the regressions in getting plain colors from themes. There were done many commits to make the code in the evolution work, and it seems like never-ending story, because it breaks "every second release".

Adwaita regression => Adwaita should fix it. Other theme (which I tried) works fine. Whom to blame then? Adwaita. That's clear, isn't it?

[1] https://git.gnome.org/browse/evolution/tree/e-util/e-web-view.c#n402

(In reply to Hussam Al-Tayeb from comment #26)
> (In reply to Milan Crha from comment #20)
> > It's not that simple in the evolution case, I'm sorry.
> 
> Can evolution fork what is needed from webkit1 into a minimal internal
> library and maintain it similar to what was done with gnomecanvas in the
> past?

Let's see. Sources of libgnomecanvas are ~250KB, unpacked webkitgtk-2.4.9.tar.xz is ~98MB, with ~6MB for Sources/WebKit2 and ~10MB for Documentation. That is still like ~80MB of sources to check what can be removed and what not and then fork it and maintain it. But wait, if we are talking about security, it will not help at all, it'll still be the old webkit1.

Thus no, it's not doable.

I am not against a port of the Evolution to use WebKit2, there are good reasons to do it, but the work on it is not simple. And if you have like 1.5 man for the evolution*, while there is still quite many other work which should be done, then it makes sense that the port goes into the background. Because of lack of man power. The Evolution is not simple, and it is not only about it, but also about evolution-data-server, evolution-ews and evolution-mapi. It's not that complex as WebKit project, luckily, but you also do not have 1.5 man to work on WebKit.

(In reply to Hussam Al-Tayeb from comment #26)
> Can evolution fork what is needed from webkit1 into a minimal internal
> library and maintain it similar to what was done with gnomecanvas in the
> past?

Making a "minimal" fork of WebKit would be an order of magnitude more effort than upgrading to WebKit2.

(In reply to Milan Crha from comment #27)
> (In reply to Michael Catanzaro from comment #23)
> > mcatanzaro:  An email client that renders HTML but doesn't get security
> > updates is not really a good thing....
> 
> I do not know what kind of security issues you are talking about. If it's
> about plugins and java script and similar, then evolution disables all but
> gtk+ plugins at its early start, the same as scripts [1].

Most of the security issues are buffer overflows, use-after-frees, and similar issues in HTML rendering. Evolution is highly vulnerable since it displays arbitrary HTML from arbitrary senders.

> I'm sorry, that sounds very selfish and bullying. You discuss that with
> whom?

On devel@lists.fedoraproject.org: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S3VHBCPMPVZ3NBKR7FQZQE6HBUHVEZ3D/

It's a downstream issue as to how long to maintain old versions of WebKit. Keep in mind that Tom is the Fedora maintainer, so the package is not likely to disappear before Evolution is ready. Also keep in mind that Fedora still has a QtWebKit package, even though the security situation there is much worse.

> Do you know what manpower is available in each project you want to
> kick off and what resources can be dedicated for the webkit2 port (or
> finding other alternative) for all those projects? It doesn't seem to. It's
> an obvious regression in the Adwaita, still you are finding ways to drop
> some software which is useless for you, but which is used by real users. Ha!
> That's great (and selfish and bullying)! What's wrong with you?

I really am sorry. We could have continued to maintain the original API indefinitely (but we wanted to delete it), or we could have chosen to provide free security updates to 2.4 (too difficult to do for free), or we could have chosen to pay for porting more apps to WebKit 2 (probably the best choice in the long run, but we'd have to port some apps to GTK+ 3!). This situation was totally avoidable, but we chose to break API, provide no security support for the old API, and help with porting only a couple apps. Now you have to live with that. :(

I understand many dependent apps don't have manpower to upgrade and will disappear. I'm glad that won't be the case for Evolution. I do think you seriously underestimate the seriousness of using an old version of WebKit which has not had real security updates for a year and a half.

(In reply to Michael Catanzaro from comment #29)
> Making a "minimal" fork of WebKit would be an order of magnitude more effort
> than upgrading to WebKit2.

Ok, understood.
> It's a downstream issue as to how long to maintain old versions of WebKit.
> Keep in mind that Tom is the Fedora maintainer, so the package is not likely
> to disappear before Evolution is ready. Also keep in mind that Fedora still
> has a QtWebKit package, even though the security situation there is much
> worse.
If you mean Qt4 version of webkit, then that is going to get obsolete on its own. Porting stuff to Qt5 is very active. Even pinentry can now use Qt5.

In terms of Gnome man-power, I take it Red Hat is providing most of it?

(In reply to Hussam Al-Tayeb from comment #30)
> If you mean Qt4 version of webkit, then that is going to get obsolete on its
> own. Porting stuff to Qt5 is very active. Even pinentry can now use Qt5.
> 
> In terms of Gnome man-power, I take it Red Hat is providing most of it?

To be clear: the version of WebKit in Qt5 is much older and less secure than the version of WebKit used by Evolution. QtWebKit was removed from the WebKit project when its maintainers announced they were switching to work on Chromium (QtWebEngine). It is still maintained in Qt, but a cursory check of the repository shows it is not getting security backports.

You should make sure the Qt programs you use are using QtWebEngine (Chromium) and not QtWebKit. Note that QtWebEngine is not packaged in distros yet, and a huge number of programs are using QtWebKit.

I'm kind of lost here, no idea why things are working correctly in other themes, but not in adwaita, so I have no idea how to fix this. Any hints Michael?

(In reply to Lapo Calamandrei from comment #32)
> I'm kind of lost here, no idea why things are working correctly in other
> themes, but not in adwaita, so I have no idea how to fix this. Any hints
> Michael?

The problem is that you switched Adwaita from using widget paths to using CSS nodes. Other themes have not switched yet, so they still work, but they will break as soon as they start using CSS nodes. In the meantime, those themes are broken in modern WebKit and presumably also GTK+ 3.20.

Modern WebKit supports CSS nodes, but not the old version used by Evolution. The easiest way to fix this is to backport support for CSS nodes to WebKitGTK+ 2.4 and do a 2.4.10 release. The strong argument for doing that is that it would fix this bug. The argument to not do so is https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

We need to decide what to do.

P.S. Mathias, it turns out that you are the webkitgtk3 maintainer in Fedora, did you know that? You were asking me about a downstream fix; seems that's your call.

(In reply to Michael Catanzaro from comment #33)
 
> We need to decide what to do.
> 
> P.S. Mathias, it turns out that you are the webkitgtk3 maintainer in Fedora,
> did you know that? You were asking me about a downstream fix; seems that's
> your call.

I'm the nominal owner of many packages... there's no good options here, I'm afraid:

1) Drop old webkit. That will kill not only evolution, but also the possible replacement, geary (well, thats dead anyway)

2) Don't touch old webkit. This leaves evolution unusable due to the theme issues

3) Patch the theme issues in the old webkit. This leaves the security holes

I think the last option is the least bad of the three.

I'll try to find some time to make a new 2.4 release, probably after we branch for 2.12 (but before 2.12/GNOME 3.20), because now we have a lot of work.

OK, it's probably the least-bad option.

Perhaps we should limit the 2.4 release to only theme fixes.

(In reply to Michael Catanzaro from comment #36)
> OK, it's probably the least-bad option.
> 
> Perhaps we should limit the 2.4 release to only theme fixes.

I don't see why, if I'm going to book some time to make a release, why not merging other fixes? like security issues? Many of the issues fixed after 2.4 don't really apply to 2.4 because they were introduced later, so it shouldn't be that much.

The issue is that providing sporadic security updates creates confusion as to the security status of the product. We should either provide regular, comprehensive security updates, or else none at all. So I would rather not merge any security fixes unless you feel confident in getting all that are applicable, and in doing regular security updates for 2.4 in the future, indefinitely or until some predetermined date. If you want to take that up, it would be *awesome* for apps stuck on 2.4 and it would take away the urgency of upgrading apps to WK2. But it might also be self-defeating with respect to some recent discussions.

(In reply to Michael Catanzaro from comment #38)
> The issue is that providing sporadic security updates creates confusion as
> to the security status of the product.

On the contrary, a user is likely to think an update contains more than theme compatibility fixes and will probably think this also fixed security and stability bugs.

(In reply to Michael Catanzaro from comment #38)
> The issue is that providing sporadic security updates creates confusion as
> to the security status of the product. We should either provide regular,
> comprehensive security updates, or else none at all. So I would rather not
> merge any security fixes unless you feel confident in getting all that are
> applicable, and in doing regular security updates for 2.4 in the future,
> indefinitely or until some predetermined date. If you want to take that up,
> it would be *awesome* for apps stuck on 2.4 and it would take away the
> urgency of upgrading apps to WK2. But it might also be self-defeating with
> respect to some recent discussions.

I don't understand this reasoning, you can still consider it insecure if you want, but let's fix security bugs for our users. We always said that wk1 was in maintenance mode, we never said it was abandoned, and that's why we kept the 2.4 branch alive. A different thing is that, it's very low priority for us, so I usually only do new releases when the 2.4 branch users request it. Last time it was to fix win32 issues and the GObject dom cache issues that Milan wanted to get fixed. Apps should move to wk2 asap in any case.

(In reply to Carlos Garcia Campos from comment #40)
> I don't understand this reasoning, 
...
> Apps should move to wk2 asap in any case.

The issue is that if we expect apps to move to wk2 asap, doing more 2.4 releases harms this effort; developers will see we are still doing wk1 releases and see less urgency to switch. Throwing in security fixes as well will magnify that effect. We would be inadvertently reducing pressure on apps to migrate to wk2, which in the long run could make users even less secure than they would be if we were to not release any updates. (If we plan to provide serious, regular security updates, then of course that would be great, but that's clearly not what you're planning.)

Perhaps, instead of a 2.4 release, we could release a patchset for the theme issues to distributor-list that is tested to apply on 2.4.9. That would fix this bug in all distros we care about, without any adverse impact. I could handle this if you want; less work for you?

(In reply to Michael Catanzaro from comment #41)

> Perhaps, instead of a 2.4 release, we could release a patchset for the theme
> issues to distributor-list that is tested to apply on 2.4.9. That would fix
> this bug in all distros we care about, without any adverse impact. I could
> handle this if you want; less work for you?

That would be fine with me.

I've prepared a new 2.4 release with the theme fixes (and some CVEs fixed). I've only tested it with GTK+ from git master and I know it builds with GTK+ 2 (yes 2.4 still supports gtk2 in WebKit1), but I don't know if I've broken the gtk2 rendering or even if it builds/works with GTK+ < 3.19. So, it would help if someone, who still uses WebKit1 (Milan?), could test the new tarball before I make it public officially. It would be great to ensure I haven't broken the windows build either. I've uploaded the tarball here:

https://people.freedesktop.org/~carlosgc/webkitgtk-2.4.10.tar.xz

Thanks.

I compiled and installed the webkitgtk-2.10.4.tar.xz tarball.
evolution 3.19.91 compiled correctly and runs fine.

empathy no longer compiles though http://pastebin.com/raw/XX3Aik8u

(In reply to Hussam Al-Tayeb from comment #44)
> I compiled and installed the webkitgtk-2.10.4.tar.xz tarball.
> evolution 3.19.91 compiled correctly and runs fine.
> 
> empathy no longer compiles though http://pastebin.com/raw/XX3Aik8u

Nevermind. passing --disable-werror makes it continue compiling.

thanks for the release, Carlos.

(In reply to Hussam Al-Tayeb from comment #44)
> I compiled and installed the webkitgtk-2.10.4.tar.xz tarball.
> evolution 3.19.91 compiled correctly and runs fine.
> 
> empathy no longer compiles though http://pastebin.com/raw/XX3Aik8u

I guess you mean 2.4.10 not 2.10.4. Thanks for trying, Milan also tried it and reported build errors with gtk3 < 3.19 that I've already fixed.

(In reply to Carlos Garcia Campos from comment #47)
> (In reply to Hussam Al-Tayeb from comment #44)
> > I compiled and installed the webkitgtk-2.10.4.tar.xz tarball.
> > evolution 3.19.91 compiled correctly and runs fine.
> > 
> > empathy no longer compiles though http://pastebin.com/raw/XX3Aik8u
> 
> I guess you mean 2.4.10 not 2.10.4. Thanks for trying, Milan also tried it
> and reported build errors with gtk3 < 3.19 that I've already fixed.

Yes, I meant to type 2.4.10. Sorry.

Thanks again for the update!

(In reply to Matthias Clasen from comment #14)
> The warning means that doing things like this:
> 
> /* widget is in, say NORMAL state */
> context = gtk_widget_get_style_context (widget);
> gtk_style_context_get_color (context, GTK_STATE_SELECTED, &color);
> 
> is broken in the sense that it causes an invalidation out of the drawing
> code (leading to new drawing causes another invalidation...)
> 
> You can do the following to avoid the problem (and the warning):
> 
> /* widget is in, say NORMAL state */
> context = gtk_widget_get_style_context (widget);
> gtk_style_context_save (context);
> gtk_style_context_set_state (context, GTK_STATE_SELECTED);
> gtk_style_context_get_color (context, gtk_style_context_get_state (context),
> &color);
> gtk_style_context_restore (context);

That is not going to work with
https://bugzilla.gnome.org/show_bug.cgi?id=761870#c2

I've just uploaded a new tarball with the build fixes reported by Milan, and a few other merges from fedora and debian. Please try again :-)

https://people.freedesktop.org/~carlosgc/webkitgtk-2.4.10.tar.xz

I plan to make the 2.4.10 release during this weekend. There's only one thing pending, latest changes in GTK+ broke the scrollbars again, I already reworked it in master, but backporting those patches to 2.4 is not that easy, because scrollbars were working in 2.4 until very recently so I didn't backport the previous fixes either. This only affects the non main frame scrollbars, because in WebKit1 main frame scrollbars are the GtkScrolledWindow ones, so I don't think it's worth the effort of making scrollbars work with GTK 3.20 in 2.4 (they should still work just fine with previous versions of GTK+). So, I'm not going to do it, I'm so tired of fighting with the theming code, but if someone wants to do it, patches are of course welcome. Otherwise I'll make the release tomorrow or next Monday.

The foreigndrawing example in gtk3-demo has been updated to show a working example of scrollbar drawing

(In reply to Milan Crha from comment #15)
> What should be done, instead of the runtime warning, is to do this
> save && restore call inside the function, when the states do not match.
> 
> Would it be that hard in gtk, that the API forces each single caller of the
> function to change one liner to 4 lines of the code?

I didn't see an answer to this.

Is there an intrinsic reason why gtk_style_context_get can't be made to do what one would expect from the API?

Even if inefficient, it would save some embarrassment.

gtk_style_context_save/restore won't work of course, but would _get/if !=/_set/_set?

(In reply to Karl Tomlinson from comment #53)
> Is there an intrinsic reason why gtk_style_context_get can't be made to do
> what one would expect from the API?

Feel free to move to bug #763796 with this part.

Ah, thanks, Milan, for the link, and I actually didn't read comment 14
carefully enough.  Sounds like it does still do what one would expect, even if
it may cause an unnecessary invalidation.  And doing get/set/set would cause
the same invalidation, I assume.

Thanks, Matthias for
https://git.gnome.org/browse/gtk+/commit/?id=5c63ab26da9297306290eb1aa540ac34caf80b9a
which is all I needed it seems.

I still see this issue, i.e. selected text is white on white, on GNOME 3.20 (Adwaita theme) with webkitgtk 2.4.10 and evo 3.20. If I am missing something, please be kind enough to point it out. Thank you very much.

List of relevant installed packages:
S | Name                  | Type        | Version    | Arch   | Repository             
--+-----------------------+-------------+------------+--------+------------------------
i | Evolution             | application |            | noarch | (System Packages)      
i | evolution             | package     | 3.20.0-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
i | evolution-data-server | package     | 3.20.0-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
i | libwebkitgtk-1_0-0    | package     | 2.4.10-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
i | libwebkitgtk-3_0-0    | package     | 2.4.10-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
i | libwebkitgtk2-lang    | package     | 2.4.10-1.1 | noarch | openSUSE-Tumbleweed-Oss

It's working for me in F24, but I couldn't tell you what the magic difference is...

Sorry, my mistake. After updating my webkitgtk to a rebuilt version, this is working correctly now. Sorry for the noise.

Closing this then

On archlinux, with webkitgtk3 2.4.10-1 and evo 3.20.0, Adwaita theme, selected text is white on white :(

(In reply to Bastien Durel from comment #60)
> On archlinux, with webkitgtk3 2.4.10-1 and evo 3.20.0, Adwaita theme,
> selected text is white on white :(

Make sure that webkitgtk3 is built using gtk 3.20 - we had that problem too in openSUSE while gtk3 was updated, webkitgtk3 had not been rebuilt using gtk3 3.20

I've rebuilt it and it works, thanks :)