See also: bug #2061994 for RHEL 8.7

Michael, looking at the current 2.36.0 changelog I stumbled on one thing - "Add new accessibility implementation using ATSPI DBus interfaces instead of ATK." - is this internal change only on something user facing changed as well? Will there be any fallout for our QE and their testing? Will they need to adapt the tests for applications that are using WebKitGTK?

You shouldn't notice any difference, except for bugs fixed or introduced. ;)

As usual, there will be several more updates throughout the 9.1 lifecycle, so I'll leave this bug in the ASSIGNED state, but the major update 2.34 -> 2.36 has landed now and is ready for testing. Further updates will be 2.36.x point releases, which are less likely to break things.

There is one known regression in Evolution, which Milan is aware of, https://gitlab.gnome.org/GNOME/evolution/-/issues/1835. I think he's planning to update Evolution to avoid that, but that's optional since it won't be hit unless using custom themes.

(In reply to Michael Catanzaro from comment #6)
> so I'll leave this bug in the ASSIGNED state,

Just kidding, bug has to go to MODIFIED for the erratum to be created.

(In reply to Michael Catanzaro from comment #6)
> There is one known regression in Evolution, which Milan is aware of,
> https://gitlab.gnome.org/GNOME/evolution/-/issues/1835.

And https://bugs.webkit.org/show_bug.cgi?id=239429 , which is even more sever, because causes crashes.

(In reply to Milan Crha from comment #10)
> And https://bugs.webkit.org/show_bug.cgi?id=239429 , which is even more
> sever, because causes crashes.

That looks like hardware acceleration is broken for a particular user. This is expected to crash always in 2.36 because hardware acceleration was enabled only as-needed prior to 2.36, but now it is enabled always. This is a good change, and it's expected to crash for users with broken hardware acceleration. It will need to be dealt with on a case-by-case basis, as every user is likely to have a different reason for crashing here. I can't help with this: it must be investigated by graphics experts.

Disabling hardware acceleration in Evolution is possible, but not a solution as it will leave all other apps using WebKit broken. I don't see any particular need for you to do anything about it. Users who are affected will just need to report bugs and hope for the best.

Yes and no. There are multiple users claiming the issue. A new one in 2.36.x is also about no content being rendered [2]; there had been also multiple users with that problem. Whether it's related to the hardware acceleration I do not know, but it seems it is.

[2] https://gitlab.gnome.org/GNOME/evolution/-/issues/1884

(In reply to Milan Crha from comment #12)
> Yes and no. There are multiple users claiming the issue.

It's not surprising, but as these issues are generally hardware-specific it's not possible to guess whether they're the same bug or not. It's going to crash in the same place even if the underlying problems are different. Each case needs to be investigated by graphics experts.

> A new one in 2.36.x
> is also about no content being rendered [2]; there had been also multiple
> users with that problem. Whether it's related to the hardware acceleration I
> do not know, but it seems it is.

That's another hardware acceleration problem, so again it's not too surprising, and again would need help from graphics experts to resolve.

My only concern here would be whether fixing CVE-s worth broken applications. The price can be significant. Or not. I do not know. Though for RHEL 8 it should be a different story, due to stability concerns. Again, maybe.

After further discussion, I'll (probably) disable the change in RHEL 8, but will leave it in RHEL 9. Affected users should report bugs and hope that graphics developers will take interest in fixing them. Upstream has moved on to always-on hardware acceleration, and I don't want to patch this out for the lifetime of RHEL 9.

(In reply to Michael Catanzaro from comment #15)
> After further discussion, I'll (probably) disable the change in RHEL 8

Well I have a revert patch prepared, but I'm getting cold feet. Let's continue to discuss in bug #2061994, since this is only about RHEL 8 at this point.

(In reply to Michael Catanzaro from comment #15)
> After further discussion, I'll (probably) disable the change in RHEL 8, but
> will leave it in RHEL 9. Affected users should report bugs and hope that
> graphics developers will take interest in fixing them. Upstream has moved on
> to always-on hardware acceleration, and I don't want to patch this out for
> the lifetime of RHEL 9.

You should sync with the Graphics team so they know what it means for them (adding Niels and Carlos for awareness).

Silly question maybe, but what is "hardware acceleration" in the context here? Is it just that WebKit wants to use OpenGL, or do accelerated media decoding, or is it something completely different?

It's OpenGL.

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: webkit2gtk3 security and bug fix 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-2022:8054