Bug 1883304

I can reproduce bug #1888623 when I boot GNOME Shell under X11. I suppose RHEL8 has different rules than Fedora with respect of the X11 support. Steps:
a) log in to GNOME Shell under Xorg
b) run Evolution in the Mail view
c) drag a message from the message list to the folder tree on the left

When dragging directly to the folder tree the folder tree properly reacts to the motion (highlights the row the cursor is above, changes the icon based on the Ctrl/Shift key press), but once the cursor moves also above the message preview (which is a WebKitWebView descendant), the folder tree stops to react to the cursor motion.

Apart of this I didn't notice any issue with the 2.30.1.

(In reply to Milan Crha from comment #5)
> I can reproduce bug #1888623 when I boot GNOME Shell under X11.

Let's see if I can bisect it....

From bug #1888623, I see this bug occurs only (a) when running under X11, which is a non-default fallback session in RHEL 8, and (b) only when the message is dragged through the web view rather than directly to the destination folder. I actually missed step (b) at first until I read your comment #5 more closely, so I think most users probably won't even notice. I'll still try to bisect it, but this seems pretty minor (at least, I would expect more serious regressions whenever we rebase WebKit), so I don't think it's a blocker for the rebase. I'll follow up in bug #1888623 if I manage to bisect it.

(In reply to Michael Catanzaro from comment #7)
> (at least, I would expect more serious regressions whenever we rebase WebKit)

Yup, I agree, I'd not consider this a major issue. I wanted to mention it here (also) for completeness. My smoke testing did not show anything else, even it was not anything comprehensive.

From the evolution-list traffic I see an increased requests about failed printing. That being "Printer not found" and when printing to a file that the WebKit cannot access local file name (with garbled UTF-8) [1]. I know the workaround, but there are many requests about printing recently, which surprised be. I'd not expect people print that much.

How will this work in RHEL? Will the sandboxing be disabled by default, until the printing [1] is fixed? I'd like to avoid support tickets about printing when we know about it beforehand.

[1] https://bugs.webkit.org/show_bug.cgi?id=202363

WebKit is not sandboxed in RHEL 8.

That will be a problem for RHEL 9, though.

(In reply to Michael Catanzaro from comment #10)
> WebKit is not sandboxed in RHEL 8.

Aha, good. I've been afraid of an increased support tickets.

Michael, do you have a (test) build with a fix for [1], please? When I retest bug #1902630 with the fixed Evolution I see the drag partly aborts, causing the mouse to still have the drag cursor and having the mouse completely unusable, while the keyboard input is possible.

[1] https://bugs.webkit.org/show_bug.cgi?id=218562

There is a build of webkit2gtk3-2.30.3-1.el8 available that you can test, but it's stuck in the gating repo because one of the CI runners failed. I'll try to get it past gating, but you can install it manually in the meantime.

Thanks. Installing manually is fine. I can confirm webkit2gtk3-2.30.3-1.el8.x86_64 fixes the drag drop issue referenced in comment #12.

I installed RHEL-8.4.0-20210108.n.0, added a google account, and Verified with webkit2gtk3-2.30.4-1.el8 in X11 and Wayland.

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: GNOME 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-2021:1586