Closed Bug 1478283 Opened 6 years ago Closed 5 years ago

[Wayland-1.15][KDE] Firefox is rendering only a blank page

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox63 --- affected

People

(Reporter: stransky, Assigned: stransky)

References

(Blocks 1 open bug,
URL
)

Details

+++ This bug was initially created as a clone of Bug #1444437 +++ Fix at Bug 1444437 is insufficient, let's fix that here.
Assignee: nobody → stransky
No longer depends on: 1444437
Hm, the KDE Plasma is still a bit raw so let's wait until it's polished a bit. I tested various Wayland examples here and regularly KDE crashes and Wayland applications has missing decorations. From the indices I see that KDE Wayland compositor is somehow slow/laggy and does not release wl_buffers in time (that also happens on other apps). I managed to render Firefox via. EGL but such windows are "invisible" to window manager - I can't interact with them.
Hello Martin, thanks for your feedback. I do use Wayland since a long time on KDE Plasma and the normal desktop is very stable for me. There are corner cases, but they are related mostly to some games. First I would like to outline, that the issue of not having Window boarders is a regression of Gtk, there is a long discussion and finally a fix from a KDE developer https://gitlab.gnome.org/GNOME/gtk/issues/1019. It should be fixed with the next Gtk release. I have the same issue with LibreOffice and Virt-Manager, but at least the applications continued to work on Wayland. So we might say we need to wait until Gtk is getting a little polish as well :-) I can only assume that you have tested with the Fedora. Which version of Plasma and Qt did you use? And which GPU and driver? When I tested it last time, my laptop with a Intel GPU worked great on Wayland with Fedora (modesetting driver). I do use Plasma 5.13.4 on Arch Linux on all my system, I play even games in 4k on Wayland and XWayland. I didn't notice that Plasma on Wayland is slow, but if you can provide some indications to me where it is slow/laggy and where I can see that the release of wl_buffers is slow too, I can ask the Kwin developers for support, they are usually answering quite fast on bug reports of Wayland. Thank you, I appreciate your work a lot to move Firefox to Wayland!
(In reply to rainer from comment #2) > Hello Martin, thanks for your feedback. I do use Wayland since a long time > on KDE Plasma and the normal desktop is very stable for me. There are corner > cases, but they are related mostly to some games. First I would like to > outline, that the issue of not having Window boarders is a regression of > Gtk, there is a long discussion and finally a fix from a KDE developer > https://gitlab.gnome.org/GNOME/gtk/issues/1019. It should be fixed with the > next Gtk release. I have the same issue with LibreOffice and Virt-Manager, > but at least the applications continued to work on Wayland. So we might say > we need to wait until Gtk is getting a little polish as well :-) Good to hear. > I can only assume that you have tested with the Fedora. Which version of > Plasma and Qt did you use? And which GPU and driver? I have a stock Fedora 28 builds with all updates, so: plasma-*-5.13.4-1.fc28.x86_64 qt5-*-5.10.1-1.fc28.x86_64 I have Intel(R) HD Graphics 530 > When I tested it last > time, my laptop with a Intel GPU worked great on Wayland with Fedora > (modesetting driver). I do use Plasma 5.13.4 on Arch Linux on all my system, > I play even games in 4k on Wayland and XWayland. I didn't notice that Plasma > on Wayland is slow, but if you can provide some indications to me where it > is slow/laggy and where I can see that the release of wl_buffers is slow > too, I can ask the Kwin developers for support, they are usually answering > quite fast on bug reports of Wayland. > Thank you, I appreciate your work a lot to move Firefox to Wayland! What's the best point of contact here? https://bugs.kde.org/? I can report the issues directly.
Yes and if you have an issue with the compositor I would recommend to report it in "Kwin" and then "Wayland-generic". Thanks!!! I will play around again with KDE on Fedora on my systems, I'm curious to see why your experience was so different from mine :-)
(In reply to rainer from comment #4) > Yes and if you have an issue with the compositor I would recommend to report > it in "Kwin" and then "Wayland-generic". Thanks!!! > > I will play around again with KDE on Fedora on my systems, I'm curious to > see why your experience was so different from mine :-) Filed as https://bugs.kde.org/show_bug.cgi?id=397834, Thanks.
I've installed Fedora including all upgrades on a test system with a Intel GPU. Plasma Wayland felt a little slow/laggy with the defaults provided and sometimes it froze for seconds, I can confirm your experience. As soon as I got rid of the xorg-x11-drv* (especially the Intel one which is known to cause trouble, but you need to keep xorg-x11-drv-libinput) I had the normal and fluent Plasma Wayland experience again that I'm used to. Just for information. The bugs are nevertheless the same with Firefox on Plasma Wayland.
I used the inofficial flatpak of Firefox nightly for a while. For my KDE Wayland session I have to use the X11 backend (so need to use XWayland, too) but for Weston the Wayland backend is working (Weston is used without XWayland). Now I tried to start kwin_wayland without XWayland but the situation is not better. For the missing window decoration the problem is caused because of the SSD usage instead of CSD. It is a bug of the GTK+ library (at least if my reading has been correct). It has been fixed for GTK+ 3.24. The flatpak build uses Gnome SDK 3.26 which uses GTK+ 3.22. Same for Gnome SDK 3.28. I build the Firefox nightly flatpak myself using Gnome SDK master of the gnome-nightly flatpak repo. There (and for the AFAIK not yet released SDK for 3.30) the GTK+ 3.24 is used. The error you reported at the KDE bug tracker still remaints. Just want to point to the GTK+ error handling SSD. See also: * https://gitlab.gnome.org/GNOME/gtk/issues/1019 * https://gitlab.gnome.org/GNOME/gtk/merge_requests/221
According to https://bugs.kde.org/show_bug.cgi?id=397834#c19 it's a KDE bug with wl_surface attach/damage ordering.
URL: https://bugs.kde.org/show_bug.cgi?id=...
That's not quite right. That other report is messy, so let me summarise. We had (at least) 3 bugs: - input going to the wrong surface - That was all us, and is fixed - That a mishandling of damage/attach - Technically more correct, doesn't seem to make /much/ difference. - Firefox stopping sending us buffers on SHM - I don't /think/ it's us. From my logs, all callbacks are called back, all buffers (except the last one) are released, but firefox just stops sending. KWin is a bit different at releasing buffers. As it's sometimes a raster compositor we release after render, rather than doing a deep copy on receipt and then releasing then. But that's not wrong. I've made a smaller test compositor with subsurface support based on kwayland (an Qt wrapper over wayland protocols that kwin uses) and that still locks up. I don't think I can do much without some debugging from your side. Sorry
(In reply to David Edmundson from comment #9) > That's not quite right. > > That other report is messy, so let me summarise. > > We had (at least) 3 bugs: > - input going to the wrong surface - That was all us, and is fixed > > - That a mishandling of damage/attach - Technically more correct, doesn't > seem to make /much/ difference. > > - Firefox stopping sending us buffers on SHM - I don't /think/ it's us. > > From my logs, all callbacks are called back, all buffers (except the last > one) are released, but firefox just stops sending. > > KWin is a bit different at releasing buffers. As it's sometimes a raster > compositor we release after render, rather than doing a deep copy on receipt > and then releasing then. But that's not wrong. > > I've made a smaller test compositor with subsurface support based on > kwayland (an Qt wrapper over wayland protocols that kwin uses) and that > still locks up. > > I don't think I can do much without some debugging from your side. Sorry Sure, I'm willing to help here. The latest Firefox already uses triple buffering (https://bugzilla.mozilla.org/show_bug.cgi?id=1498499) which can be adjusted to any buffer number you need for the debugging purposes (needs BACK_BUFFER_NUM update and rebuild).
Hi David, as there has been no comment for two month now, it is allowed to ask if you have made some progress already?
I did try updating with larger number of backbuffers, they make it last longer especially in the test compositor - but ultimately behaviour ends up the same. From the logs, we're releasing all but the latest constantly, so no progress, I don't see anything wrong on the kwin side. BTW: fixes for the first two things are released in frameworks 5.51 which you probably have in Fedora.
I think this is depending from the configuration of Firefox. Actually I'm writing this in Firefox-nightly Wayland on Kwin. Firefox on Wayland can crash quite easy, especially when using the interface, the font DPI is not recognized so everything is super small on a 4k screen, copy and paste doesn't work, but it works at least somehow :-) I had to enable in about:config layers.acceleration.force-enabled and disable webrender. System details: Plasma 5.14.4 KDE Frameworks 5.53 Qt 5.12
(In reply to rainer from comment #13) > I think this is depending from the configuration of Firefox. Actually I'm > writing this in Firefox-nightly Wayland on Kwin. Firefox on Wayland can > crash quite easy, especially when using the interface, the font DPI is not > recognized so everything is super small on a 4k screen, copy and paste > doesn't work, but it works at least somehow :-) > > I had to enable in about:config layers.acceleration.force-enabled and > disable webrender. Yes, the GL compositor should work fine. We're also fixing some GL bugs now to make it more usable.

I've tested Firefox 2019-01-17 on Plasma 5.15 beta on Wayland. It get's unstable quite fast and then the terminal is spammed with a lot of the following messages:
###!!! [Parent][MessageChannel] Error: (msgtype=0xA00001,name=PVsync::Msg_Notify) Channel error: cannot send/recv

about:config layers.acceleration.force-enabled=true, disable webrender

I seem to be experiencing this bug on my machine. If I operate the browser blind (ctrl + t, type a known good url, press enter) and then change focus it seems to register the events, but only updates the framebuffer on focus change events (click to a different window and back.) This is on KDE Wayland with the environment variable GDK_BACKEND set to wayland. What further info can I provide to help in fixing this bug, or how else can I try to help move a fix forward?

I have tested Firefox-Nightly on Plasma 5.16 Beta today, and it works correctly until you try to move or resize the window.

I can comfirm this happens to me as well [link to testing I did] (https://www.reddit.com/r/kde/comments/d7yhmc/firefox_nightly_on_wayland_crashing/)

Important maybe bit:
"Update 4: Using wldbg (a wayland debuging tool) I found that firefox seems like it gets stuck in this loop:

[firefox ] S: wl_callback@60.done(1033)
[firefox ] S: wl_display@1.delete_id(60)
[firefox ] C: wl_display@1.sync(new id wl_callback@47)
"

I'm not really sure, but it looks like it will get stuck in indefinite loop where this just get cycled over and over again.

I don't know what happened, but after I've upgraded Firefox-nightly 72 from 20191120 to 20191127, Firefox is now completely unusable on Wayland. Before I couldn't resize the window, but I was able to browse the web without major issues. But now I just get a Firefox frame with an otherwise empty/transparent window, I cannot move the window and nothing works anymore.

I did a test with a new profile. As soon as I activate webrender, then the window is unusable and it is not drawn anymore.

firefox-nightly -p
Attempting load of libEGL.so
Attempting load of libEGL.so
[GFX1-]: We don't have EGLSurface to draw into. Called too early?
[GFX1-]: We don't have EGLSurface to draw into. Called too early?
[GFX1-]: We don't have EGLSurface to draw into. Called too early?

Initial rendering should be fixed now. Resize is tracked at Bug 1593478.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.