Just a side note:

When I run 'evolution' from a terminal and start in Mail, then when I move to Contacts then to Tasks, then I see on the console these runtime warnings:

(evolution:3111): evolution-util-WARNING **: 03:08:09.443: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::EWebViewEnsureBodyClass: Invalid page ID: 9

(evolution:3111): evolution-util-WARNING **: 03:08:09.443: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet: Invalid page ID: 9

(evolution:3111): evolution-util-WARNING **: 03:08:09.443: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet: Invalid page ID: 9

(evolution:3111): evolution-util-WARNING **: 03:08:13.528: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::EWebViewEnsureBodyClass: Invalid page ID: 21

(evolution:3111): evolution-util-WARNING **: 03:08:13.528: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet: Invalid page ID: 21

(evolution:3111): evolution-util-WARNING **: 03:08:13.528: Failed to call a DBus Proxy method org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet: Invalid page ID: 21

It does that both in RHEL 7 and 8. For easier reproducer:
a) run in a terminal: evolution -c mail
b) press Ctrl+2
c) press Ctrl+3

There are new runtime warnings after b) and c).

I did not notice any negative impact in the GUI, even though the runtime warnings are there to indicate that something expected failed. Some users are picky on runtime warnings (they do not like them in the system logs). An alternative could be to mute this runtime warning in evolution, or turn it into g_debug(), instead of using g_warning().

Hm, the RHEL 7 rebase was pulled from compose because we don't yet have a build on s390 or ppc64, which is stalled waiting for a build of GCC for those architectures. Can you confirm that you're really seeing these warnings in RHEL 7? What is the exact NVR that you have installed?

The errors look like you're suffering from the elimination of single secondary process model, but that should not affect Evolution because we have a patch to force Evolution to use the single process model. I'm simply using the patch from here: https://src.fedoraproject.org/rpms/webkit2gtk3/blob/f30/f/webkit-process.patch. If that isn't working, then I guess I need to debug it, because I don't think we should proceed with the rebase if it actually introduces runtime warnings in Evolution.

(In reply to Milan Crha from comment #7)
> When I run 'evolution' from a terminal and start in Mail, then when I move
> to Contacts then to Tasks, then I see on the console these runtime warnings:

I can reproduce.

I took the packages from brew. I'll try to figure out what is happening on the evolution side and let you know.

I added some debug prints and it looks like a timing issue. Evolution issues a web extension command on a page, which was not created yet.

  23128: e_web_view_init: 0x3634ee0

  (evolution:23128): evolution-util-WARNING **: 04:59:42.456: Failed to call...: Invalid page ID: 20

  23128:   web_view_load_string: 0x3634ee0: page_id:20
  23128:   web_view_load_string: 0x3634ee0: page_id:20
  23167: web_page_created_cb: page-id:20 page:0x20d35e0
  23128:  check_last_page_id: view:0x3634ee0 changes: 0 ~> 20

Where the number on the left is a process ID (23128 being the 'evolution' process and 23167 being the 'WebKitWebProcess'). When the WebView is created (or I do not know when exactly), it has assigned the page ID, in this log snippet number 20. Evolution calls its D-Bus methods on it, but the WebProcess side doesn't know about the page yet, thus the D-Bus call fails. Only after the web_page_created_cb() signal handler is called (on the WebProcess side) the extension knows about the page ID 20. The 'check_last_page_id' is a 1-second timeout callback I added, which checks whether the page ID changed on the UI side. It has set number 0 on the WebView create, which is what is shown at the last line of the log snippet above.

It seems the corresponding WebPage is created only after the WebView calls one of its webkit_web_view_load_... functions, but not before. Thus trying to access the WebPage before loading content to it leads to this (maybe new?) behavior. Is that a bug in WebKitGTK or a new (and expected) behavior?

I'm not sure what the right thing to do is now. I do not think that blocking the WebKitGTK rebase due to Evolution is a way to go, though, because it's not the only user of the WebKitGTK and because the rebase brings a lot of good fixes. That said, I'd rather mute the warning (by turning it into g_debug() or something like that) on the Evolution side, to have the simplest workaround/fix for this and update Evolution together with the WebKitGTK.

Just a side note, it seems I can workaround this by calling:

    webkit_web_view_load_uri (WEBKIT_WEB_VIEW (web_view), "about:blank");

at the end of the EWebView's GObject::constructed() method. I do not see the runtime warnings with that.

(In reply to Milan Crha from comment #11)
> It seems the corresponding WebPage is created only after the WebView calls
> one of its webkit_web_view_load_... functions, but not before. Thus trying
> to access the WebPage before loading content to it leads to this (maybe
> new?) behavior.

That's all expected.

> Is that a bug in WebKitGTK or a new (and expected) behavior?

Nice debugging. I was going to say this is a WebKit bug (or at least a WebKit design failure), but after reading your next comment, I see this only occurs before the first page load... considering we have a workaround, that might be acceptable.

(In reply to Milan Crha from comment #12)
> Just a side note, it seems I can workaround this by calling:
> 
>     webkit_web_view_load_uri (WEBKIT_WEB_VIEW (web_view), "about:blank");
> 
> at the end of the EWebView's GObject::constructed() method. I do not see the
> runtime warnings with that.

OK, good find. I think that's a good harmless solution for RHEL 7 and RHEL 8. I wouldn't want to leave that workaround in Evolution master, but since the bug doesn't occur in master anyway (I guess you've switched to the new messaging APIs?) we don't have to worry about that.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: webkitgtk4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4035