Bug 259858

Created attachment 467206 [details]
blank webview with drag content visible

(In reply to Jan from comment #0)
> That makes me wonder why epiphany works because
> "/org/gnome/epiphany/web/hardware-acceleration-policy" is set to "always".
> Or is the flaptak making use of its own sandboxed version of the gsettings
> database?

It is; flatpak application generally cannot read host settings. But I doubt that's relevant to this bug. Unless you've disabled hardware acceleration, it will be enabled. A quick way to test is to use the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 (e.g. flatpak run --env=WEBKIT_DISABLE_COMPOSITING_MODE=1 ...)

> A CI build of NewsFlash that hits the bug on my pc can be found here:
> https://gitlab.com/news_flash/news_flash_gtk/-/jobs/4810676070/artifacts/raw/
> io.gitlab.news_flash.NewsFlash.Devel-3.0.0-e3738cd5.flatpak

I will imminently update the master runtime to WebKitGTK 2.41.90. Please try that and report back whether it makes any difference. There have been so many graphics-related fixes recently that it probably doesn't make sense to investigate until we know whether it still occurs with all the latest fixes.

Please also test *without* WEBKIT_DISABLE_COMPOSITING_MODE and *with* WEBKIT_DISABLE_DMABUF_RENDERER=1

Had a chance to test with 2.41.90:

- view is still white with HardwareAccelerationPolicy::Always
- WEBKIT_DISABLE_COMPOSITING_MODE=1 makes things appear on the screen again
- and so does WEBKIT_DISABLE_DMABUF_RENDERER=1
- both variables together work as well, but I'd assume disabling compositing makes dmabuf obsolete?

WEBKIT_DISABLE_DMABUF_RENDERER only makes sense when accedlerated compositing is not disabled. What's the output of ls /dev/dri? I'm not sure I understand what change made it fail, was the upgrade from 2.40.5 to 2.40.6 or a flatpak sdk upgfrade? or both?

ls /dev/dri
by-path  card1	renderD128

I can't really use the gnome 44 platform with my master builds since I already rely on new features from gtk 4.12 and libadwaita 1.4.

But I tried running the stable version of NewsFlash with the master platform and could reproduce the issue there as well

flatpak run --runtime=org.gnome.Platform//master io.gitlab.news_flash.NewsFlash

will also render a completely white webview

The only change is going from org.gnome.Platform//44 -> org.gnome.Platform//master

The 'surf' autopkgtests are failing in Debian and Ubuntu, it seems it started after the 2.41.4 -> 2.41.5 update.

Testing with 2.41.91 on an ubuntu mantic GNOME or xfce env confirms the problem, WEBKIT_DISABLE_COMPOSITING_MODE=1 workaround the issue here but WEBKIT_DISABLE_DMABUF_RENDERER=1 doesn't

And when the display is empty those messages are printed

Cannot get default EGL display: EGL_BAD_PARAMETER
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

is there more information or debugging that I could provide to help there? the issue is preventing the new webkitgtk version to land in the current Ubuntu serie

Carlos thinks the problems with surf are unrelated. Please report a separate bug for surf.

So, back to the Newsflash problem. Presumably MiniBrowser is broken too, right? Can you check to be sure, please:

$ flatpak run --command=/usr/libexec/webkitgtk-6.0/MiniBrowser io.gitlab.news_flash.NewsFlash

At least we know the problem here is caused by dmabuf renderer, so at least we have a workaround that we can deploy if necessary.

(In reply to Jan from comment #6)
> But I tried running the stable version of NewsFlash with the master platform
> and could reproduce the issue there as well
> 
> flatpak run --runtime=org.gnome.Platform//master
> io.gitlab.news_flash.NewsFlash
> 
> will also render a completely white webview

I installed NewsFlash and used that command to run it using the master runtime. But unfortunately, it works perfectly fine for me. I also have an AMD GPU.

(In reply to seb128 from comment #7) 
> Testing with 2.41.91 on an ubuntu mantic GNOME or xfce env confirms the
> problem, WEBKIT_DISABLE_COMPOSITING_MODE=1 workaround the issue here but
> WEBKIT_DISABLE_DMABUF_RENDERER=1 doesn't

Oh, and this is another indication that you have a different issue. The problem Jan is hitting with NewsFlash is resolved by WEBKIT_DISABLE_DMABUF_RENDERER=1.

So since you can reproduce and I cannot, using the same flatpak and same runtime, my first thought was this would be a hardware-specific issue. But your GL renderer is:

AMD Radeon RX 580 Series (polaris10, LLVM 16.0.6, DRM 3.52, 6.4.6-200.fc38.x86_64)

while mine is:

AMD Radeon RX 570 Series (polaris10, LLVM 16.0.6, DRM 3.54, 6.5.0-0.rc7.20230821gitf7757129e3de.50.fc39.x86_64)

So yeah, we have basically the same polaris10 graphics hardware. Seems pretty unlikely that RX 580 would be broken while RX 570 is fine.

Next guess: maybe, if we're lucky, the problem was miraculously fixed in the runtime sometime between your previous comment on August 13 and today? I noticed there were some regressions in mesa recently. It's at least possible.

It is indeed a miracle. I've been  running with "WEBKIT_DISABLE_DMABUF_RENDERER=1" for quite some time now. So I tested the mini browser without and it worked. Tested NewsFlash without and it worked as well.

The only caveat is I experience some flickering on load and rare freezes where the old article doesn't disappear until I force a redraw by resizing. With "WEBKIT_DISABLE_DMABUF_RENDERER=1" the flickers are gone. But that deserves a new issue.

(In reply to Michael Catanzaro from comment #10)
> Carlos thinks the problems with surf are unrelated. Please report a separate
> bug for surf.

ack, the new bug is https://bugs.webkit.org/show_bug.cgi?id=261268