Page MenuHomePhabricator

Wayland + Firefox - windows never get rendered
Closed, InvalidPublic

Description

Running E ( git ) in wayland mode, when I launch firefox, the window contents are never rendered. The window appears to be transparent, but when you move or resize it, it becomes clearer that the window contents are in fact whatever was underneath the window when it was first created. Firefox doesn't appear to crash. The titlebar ( a gtk title bar ) only is rendered, and I can see the name of the tab I last had open.

I've tried:

  • the default Arch build of firefox ( which is supposed to support wayland )
  • firefox-developer-edition - also an Arch package, and also supposed to support wayland
  • building firefox-wayland-hg from the AUR repository

All behave the same way.

I've tried with GL and software compositing - also the same behaviour in both. When I take a screenshot with E, I get the same as I see on the screen.

I can run other gtk apps in wayland mode in E. I can run firefox in a Gnome/wayland session, with firefox in wayland mode, and it works ( quite well actually - tear-free netflix ... my goal here ).

I can run firefox in X mode ( with GDK_BACKEND=x11 ) and it works.

ProhtMeyhet added projects: Restricted Project, enlightenment-git.Aug 7 2019, 2:08 AM
ProhtMeyhet triaged this task as Showstopper Issues priority.

this is really hard. it doesn't look like a hardware issue and i'm afraid we have to make you debug further...

firefox is not really talkative, but could you still try to run it in a terminal and see if there are any error messages? please also try the option --g-fatal-warnings which should crash firefox if it encounters errors from gtk/x/wayland.

then also please upload dmesg, please one directly after a reboot because it will be shorter, and, if you are using journal from systemd, also a journalctl -b.

please also provide your kernel version and the hardware you are using.

I, for example, currently see a lot of

[  +0.000020] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[  +0.039489] [drm:radeon_uvd_cs_parse [radeon]] *ERROR* Invalid UVD handle 0x2fe60001!

 xdg-desktop-por[31577]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for the well-known name org.gnome.Shell without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag

which doesn't stop firefox from rendering, but mpv (an mplayer fork).

I've tried the default firefox and firefox-developer-edition with --g-fatal-warnings ... no errors or messages at all, unfortunately.

dmesg:

systemd logs:

This is a Lenovo Flex 14, based on the AMD Ryzen ( AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx ). I'm running a 5.2.6-arch1-1-ARCH kernel right at the moment.

eglinfo:

glxinfo:

Thanks for your time :) Let me know if there is anything else I can do to help debug.

two things

  1. did you run firefox and then took the logs? if so, there is still no error message. if not please run firefox before uploading dmesg and journalctl
  1. you said you are using wayland, but your glxinfo clearly states you are using X11. this is quite confusing.
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD RAVEN (DRM 3.32.0, 5.2.6-arch1-1-ARCH, LLVM 8.0.1) (0x15dd)
    Version: 19.1.4
    Accelerated: yes
    Video memory: 256MB
ProhtMeyhet lowered the priority of this task from Showstopper Issues to Pending on user input.Aug 8 2019, 2:43 AM

did you run firefox and then took the logs? if so, there is still no error message. if not please run firefox before uploading dmesg and journalctl

Yes I took the logs after running firefox. And yes I noticed that there was no corresponding logging output.

you said you are using wayland, but your glxinfo clearly states you are using X11. this is quite confusing.

I was absolutely running under wayland. Should glxinfo say something else under wayland/Xwayland? Anyway, taken again:

[dkasak@nanginator ~]$ glxinfo | grep -A 5 Extended
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD RAVEN (DRM 3.32.0, 5.2.6-arch1-1-ARCH, LLVM 8.0.1) (0x15dd)
    Version: 19.1.4
    Accelerated: yes
    Video memory: 256MB
[dkasak@nanginator ~]$ ps ax | grep X
17073 tty1     Sl+    0:00 /usr/bin/Xwayland :0 -rootless -listen 148 -listen 149 -terminate
17551 pts/0    SN+    0:00 grep X
[dkasak@nanginator ~]$
d.j.kasak.dk raised the priority of this task from Pending on user input to Showstopper Issues.Aug 26 2019, 7:08 PM

Switching back to previous priority ( as I've provided input ). Feel free to change priority if not appropriate ...

I will see if I can simulate this in WL ... FF version could vary... Luckily there is lots of very nice info on this ticket which helps greatly in tracking things down .. Kudos on the report :D

devilhorns added a comment.EditedAug 26 2019, 7:58 PM

Current EFL & E Versions please ? And did you try in Software Mode ?? export E_COMP_ENGINE=sw before you start (or other EFL env vars)

EFL is currently built from git commit: ce2fcda1e233731c10e0339a9e9c51175d38d0be
E is currently built from git commit: 8a35d17f5ed2a9e837d1cc5503adba4fa2ae6792

Yes I've tried running in software & GL mode, and I just tried that E_COMP_ENGINE=sw before launching E also.

Since a little while back ( maybe a week or so ), the behaviour of this bug has changed subtly. Now, Firefox renders the *first* frame only ( as opposed to what I assume was it ever rendering a frame ). I still can't interact with the window at all. Attempting to resize the Firefox window now results in an immediate crash ( ie E crashes back to the console ).

d.j.kasak.dk added a comment.EditedSep 3 2019, 5:12 PM

Thanks for the suggestion. Disabling hardware rendering in Firefox does make a subtle difference - reverts me to the original behaviour - the 1st frame is never rendered ( as opposed to *only* the 1st frame being rendered ). It also fixes that E-crash-on-resize that I mentioned in the above comment too. Current screenshot:

I've restested ( Firefox, no hardware acceleration ) with E using both software and OpenGL compositing - same behaviour.

d.j.kasak.dk closed this task as Invalid.Dec 22 2019, 12:06 AM

I've just retested this, and it's now working for me, including with hardware acceleration enabled in Firefox. Since I created this ticket, and no-one else seems to have the issue, I'm closing the ticket 'invalid'.