Bug 1817144 - Rebase WebKitGTK to 2.28
Summary: Rebase WebKitGTK to 2.28
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: webkitgtk4
Version: 7.9
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Michael Catanzaro
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1754779 1815333 1815335 1815337 1815339 1815342 1815344 1815346 1815348 1815350 1815352 1815354 1815357 1815359 1815361 1815363 1815366 1818659 1821109 1821113 1821116
TreeView+ depends on / blocked
 
Reported: 2020-03-25 16:51 UTC by Michael Catanzaro
Modified: 2020-09-29 20:58 UTC (History)
4 users (show)

Fixed In Version: webkitgtk4-2.28.2-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 20:56:14 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4035 0 None None None 2020-09-29 20:58:29 UTC

Description Michael Catanzaro 2020-03-25 16:51:22 UTC
Rebase WebKitGTK to 2.28. Older branches are EOL.

Comment 7 Milan Crha 2020-06-10 07:15:24 UTC
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().

Comment 8 Michael Catanzaro 2020-06-10 13:52:38 UTC
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.

Comment 9 Michael Catanzaro 2020-06-10 14:49:26 UTC
(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.

Comment 10 Milan Crha 2020-06-11 07:23:51 UTC
I took the packages from brew. I'll try to figure out what is happening on the evolution side and let you know.

Comment 11 Milan Crha 2020-06-11 09:24:10 UTC
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.

Comment 12 Milan Crha 2020-06-11 10:00:03 UTC
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.

Comment 13 Michael Catanzaro 2020-06-11 12:21:48 UTC
(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.

Comment 24 errata-xmlrpc 2020-09-29 20:56:14 UTC
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


Note You need to log in before you can comment on or make changes to this bug.