1567410 - Enabling both gfx.webrender.enabled and gfx.xrender.enabled in FF69 breaks keyboard navigation

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Maxim Britov]

Attachment: qqq.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

user_pref("gfx.webrender.enabled", true);
user_pref("gfx.xrender.enabled", true);

On FF68.0.1 works fine. I found this issue on 69b3 and next betas. Currently on beta6.
Desktop linux x64 + Nvidia bold. Second test host notebook with linux x64 + mesa/xf86-video-intel (i5-5300U)

Actual results:

Most keyboard navigations fails. For example address bar history, login/password history. I will attach sample with wrong selection.

Comment 1

[Darkspirit]

Hi, do you have a special use case for XRender? Please disable it, if possible.
(On Linux, gfx.webrender.enabled only works if layers.acceleration.force-enabled is enabled, too. gfx.webrender.all covers both.)

Comment 2

[Maxim Britov]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #1)

Hi, do you have a special use case for XRender? Please disable it, if possible.
(On Linux, gfx.webrender.enabled only works if layers.acceleration.force-enabled is enabled, too. gfx.webrender.all covers both.)

gfx.xrender.enabled was enables for long time. I can't remeber when and why I enable it.
gfx.webrender.enabled and gfx.webrender.all enables on Intel box may be half year ago, can't remember. On nvidia box enabled since ff69.
I have gfx.webrender.enabled == true, gfx.webrender.all == true, layers.acceleration.force-enabled == true
Met issue and just track down it to two options in prefs.

Comment 3

[Darkspirit]

Met issue and just track down it to two options in prefs.

Thanks for confirmation! :)
You can clean up your about:config by adopting these settings:
gfx.webrender.all = true
gfx.webrender.enabled = false (default)
gfx.xrender.enabled = false (default)
layers.acceleration.force-enabled = false (default)

---

XRender was deprecated by bug 1180942 and bug 1241832. It was left for X sessions over the network:

(Nicolas Silva [:nical] from bug 1263222 comment 1)

X fowarding being slower with xrender compsoiting disabled is not surprising. Do we care about this kind of setup, though?
If so we could keep the xrender compositor around and just enable it for this use-case (I am not super found of doing this).

In 2011, XRender support was added to Chromium: https://codereview.chromium.org/6793005 (But doesn't seem to use it anymore?)
In 2017, a user mentioned that only Epiphany would support XRender, too: https://lists.x2go.org/pipermail/x2go-user/2017-January/004223.html
Also found this: https://www.scm.com/doc/Installation/Remote_GUI.html#opengl2-with-x11-over-ssh
(LIBGL_ALWAYS_INDIRECT=1 doesn't seem to be a solution: "indirect rendering uses the GLX protocol to relay the OpenGL commands from the program to the hardware, which limits OpenGL capabilities to OpenGL 1.4.")

Remote desktop and thin clients are done differently today.
Given Mozilla is investing in Wayland, has barely manpower to fix X11 issues and does not even have offical builds for Raspberry Pi (which would likely be more important) I would like to propose hiding the pref from about:config first, making it non-functional if WebRender is enabled and removing support as soon as WebRender is rolled out.

Comment 4

[Darkspirit]

Let's see if this naive patch gets accepted or if a different solution is preferred.

• WebRender Linux rollout could become painful if users still have such ancient prefs without knowing (comment 0). I have seen some old tutorials recommend enabling XRender.
• If XRender is enabled, the autoscroll icon is corrupted every second usage: Instead of showing the autoscroll icon, the tiny area it should appear on scrolled with the page as if it was a tiny screenshot. I did not invest more time to uncover further bugs.
• Users of X Forwarding and XRender likely have telemetry disabled. They should be given time to upgrade to a more modern solution: Remote desktop and cloud gaming use video streams with success. This patch would prevent XRender usage unless gfx.webrender.force-disabled is true. If gfx.webrender.force-disabled would be replaced in the future with something like gfx.webrender.force-software, XRender support should rather have been removed by then. This patch should ride the trains before WebRender Linux rollout. If users of X Forwarding notice what has happened and file a performance bug, they can be made aware of the temporary workaround setting gfx.webrender.force-disabled to true, so they can use XRender a few more months until they have modernized their systems.
• Other bugs want the same direction of sharing code paths: bug 496204 (bug 720523), bug 788319 (bug 1474281, bug 1563035).
• Related: gfx.use-glx-texture-from-pixmap is anyway broken (bug 1561976): Due to bug 788319 I assume it should be wontfixed. If it was worth, DMABUF (bug 1552590) could be implemented for X11 as well (bug 1010527 comment 28). Debian 10 (buster/stable) already defaults to Gnome on Wayland.

Alternatives

• Renaming XRender pref before WebRender Linux rollout
• Automatically disabling XRender as soon as WebRender is enabled
• Fixing WebRender + XRender combination and maintaining this configuration

("Remove X11BasicCompositor" patch should demonstrate the code size of XRender: bug 1241832 comment 15 mentioned how bad Chromium and Firefox without XRender were.)

Comment 5

[Darkspirit]

Attachment: Bug 1567410 - Prevent XRender usage unless WebRender is force-disabled.

Comment 6

[Darkspirit]

Attachment: Bug 1567410 - Rename XRender pref.

Comment 7

[Darkspirit]

Attachment: Bug 1567410 - Remove X11BasicCompositor.

Comment 8

[Darkspirit]

This could be fixed by bug 1551598.

Comment 9

[Darkspirit]

Comment 0 has been fixed by not using a separate window anymore (bug 1551598).
Just checked: It only happened with WebRender + XRender + GPU Process. It did not happen with OpenGL + XRender + GPU Process.
Bug 1567791 is about the remaining problem when hovering main menu items.

Comment 10

[Maria Berlinger [:mberlinger], Services QA]

I've managed to reproduce this issue on an affected Firefox 69.0b4 on Ubuntu 18.04x64 by following the STR from comment 0.

This is verified fixed using Firefox 70.0b10 on Ubuntu 18.04x64.