Bug 228268

Ah, interesting. I've discovered the rendering isn't actually pure white, but slightly darker. I ramped up my Night Shift intensity in the GNOME settings app, and I can slightly make out some text from the WebView in a very light grey. The developer tools, accessed from the 'Inspect Element' context menu option, are completely invisible, however. Context menus, like the rest of the GTK elements, appear to be working just fine.

I've made a discovery regarding the page loading failure. Based on the errors, I guessed it was an issue with HTTPS. I've been able to connect to 'http://neverssl.com/' and 'http://example.com' (as opposed to the https version) consistently. I'm now updating the bug report title to mention this issue

(In reply to Emil Sayahi from comment #0) > Additionally, almost all page loads fail while emitting any of the following > warnings: > ``` > (process:70483): GLib-Net-WARNING **: 17:44:39.051: > ../glib-networking/tls/gnutls/gtlscertificate-gnutls.c:161: invalid property > id 3 for "private-key" of type 'GParamBoxed' in 'GTlsCertificateGnutls' > > (process:67609): GLib-GIO-WARNING **: 17:13:47.931: > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 12 for > "protocol-version" of type 'GParamEnum' in 'GTlsClientConnectionGnutls' > > (process:67609): GLib-GIO-WARNING **: 17:13:47.931: > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 13 for > "ciphersuite-name" of type 'GParamString' in 'GTlsClientConnectionGnutls' > ``` This means your glib is too old: somehow, you built glib-networking against a newer glib than you're using at runtime. You need to make sure that the software in your runtime environment is never older than the software in your build environment.

(In reply to Michael Catanzaro from comment #3) > (In reply to Emil Sayahi from comment #0) > > Additionally, almost all page loads fail while emitting any of the following > > warnings: > > ``` > > (process:70483): GLib-Net-WARNING **: 17:44:39.051: > > ../glib-networking/tls/gnutls/gtlscertificate-gnutls.c:161: invalid property > > id 3 for "private-key" of type 'GParamBoxed' in 'GTlsCertificateGnutls' > > > > (process:67609): GLib-GIO-WARNING **: 17:13:47.931: > > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 12 for > > "protocol-version" of type 'GParamEnum' in 'GTlsClientConnectionGnutls' > > > > (process:67609): GLib-GIO-WARNING **: 17:13:47.931: > > ../subprojects/glib/gio/gtlsconnection.c:397: invalid property id 13 for > > "ciphersuite-name" of type 'GParamString' in 'GTlsClientConnectionGnutls' > > ``` > > This means your glib is too old: somehow, you built glib-networking against > a newer glib than you're using at runtime. You need to make sure that the > software in your runtime environment is never older than the software in > your build environment. I built and installed GLib from the GNOME GitLab. I then used that very same version when compiling `libsoup-3.0`. You can see this in the script I'm using to build WebKit (https://raw.githubusercontent.com/Dirout/oku/90034f7d55649026a61ead2e934226870a1cb607/build-dependencies.sh). Just to ensure this is the case, I've rebuilt and reinstalled, in order of mentioning, GLib, Libsoup, and WebKitGTK. Afterwards, I rebuilt my browser. Neither issue has been resolved, and I continue to receive the very same GLib-GIO warnings regarding HTTPS.

Try building glib-networking as well?

(In reply to Michael Catanzaro from comment #5) > Try building glib-networking as well? Thanks, that fixed it. Building & installing GLib, glib-networking, libsoup, and then WebKit, in that order, now allows for successful HTTPS connections. Now removing mention of this from the bug report title. Now all that remains is the original issue, the blanked out WebView. It is being properly rendered somehow, as dragging page elements like images or highlighted text makes them visible while dragged, but the actual WebView GTK widget itself is almost pure white.

I've compiled the MiniBrowser, and this rendering issue also affects that. Now I know for certain it's not something related to my code or browser.

Someone has tested and informed me via Reddit that this bug is present on Nvidia GPUs, but not Intel graphics. Source: https://reddit.com/r/GTK/comments/owvlen/how_does_gtk4_webkit_render_for_you/h89w498/ This would be a regression, as the stable, GTK3 releases of WebKitGTK do not have this terrible rendering bug on Nvidia.

Adding bug192879 as it might be related (changed the isInAcceleratedCompositingMode implementation)

Sorry. Wrong bugzilla page... #facepalm

Hi Emil, can you confirm that this is still broken] I expect so, since nobody has attempted to fix it, but it's been half a year, and occasionally the bug gremlins take pity and fix things for us if we wait long enough....

Hello Michael, I can't speak for myself, but the bug seems to still be present in the version that is currently shipped in "org.gnome.Platform" master. So probably a somewhat recent version of webkit master/main? I'm getting feedback from people trying the Gtk4 port of my feed reader. https://gitlab.com/news-flash/news_flash_gtk/-/issues/318 https://gitlab.com/news-flash/newsblur_api/-/issues/2#note_899952104

Created attachment 460310 [details] Picture of broken rendering Broken rendering on nvidia as of git commit 54f1485d92416e5b27b10fef5b47e9c4844f53d7

(In reply to Michael Catanzaro from comment #11) > Hi Emil, can you confirm that this is still broken] I expect so, since > nobody has attempted to fix it, but it's been half a year, and occasionally > the bug gremlins take pity and fix things for us if we wait long enough.... I forgot this was still open. Yes, it remains broken for me to this date. On Arch Linux with an NVIDIA GTK 970, all up-to-date packages (NVIDIA drivers, GNOME 42, webkit2gtk-5.0, GTK4 dev packages, etc). I found [this video](https://youtu.be/xm6AiWzdERc) of someone trying the GTK 4 branch of GNOME Web and they appear to encounter the same problem unless they force dark mode. That doesn't appear to be a fix for me

Created attachment 460638 [details] Screenshot of correct rendering with dark mode To further add to my previous comment: After switching my browser over to `libadwaita` and enforcing a dark mode through `libadwaita::StyleManager` as opposed to `gtk4::Settings.gtk_application_prefer_dark_theme`, the rendering does appear to get fixed, as that YouTube video that I'd found appeared to show.

Created attachment 460639 [details] Screenshot showing rendering irregularity with dark mode It appears, however, that things still appear to be abnormally bright, as demonstrated with this screenshot of Reddit in my own browser. This is not the case in Google Chrome or Firefox (will post comparison screenshot in next comment).

Created attachment 460640 [details] Screenshot showing correct rendering in other browser This is Reddit in Google Chrome, as a point of comparison to show how bright WebKitGTK still appeared, even when things were made visible with the switch to `libadwaita`'s forced dark mode. I tried taking a screenshot in pre-GTK4 GNOME Web instead of Google Chrome, but it appears running my own browser causes the WebKitGTK component to become non-functional in GNOME Web until I restart my PC. This is true in the reverse—when, last night, I switched my browser to `libadwaita` (it was already using GTK4, FYI) the WebKit component decided to stop working completely, spitting out errors in the terminal, while GNOME Web operated fine. This remained the case until I restarted my PC this morning and attempted running my own browser again, when it started magically working without any code changes, but apparently caused GNOME Web to break. If you want to tinker around with my GTK4 + libadwaita + webkit2gtk-5.0 web browser to debug things yourself, the source code is here: https://github.com/Dirout/oku/ (latest commit is https://github.com/Dirout/oku/commit/dda8ee0c11e520a78c69e77e0ba00726bb032436 as of posting this comment). To run it, install the Rust compiler toolchain and run `cargo run --release` inside the source code directory.

Looks like this is going to be a blocker for GTK 4. Does Igalia plan to investigate this? I can try to pull in Red Hat graphics people if that would help?

(In reply to Michael Catanzaro from comment #18) > Looks like this is going to be a blocker for GTK 4. Does Igalia plan to > investigate this? I can try to pull in Red Hat graphics people if that would > help? This offer is still available.

I will ask Red Hat to see if we might help with this.

Created attachment 464540 [details] Test patch for glvnd Hi, we'd like an NVIDIA user who is willing to rebuild glvnd to try a debug patch to see if we have a synchronization problem in GTK and/or WebKit. This patch is a hack that's only suitable for debug purposes. Goal is to see if this fixes the rendering issue or if it makes no difference. Emil, if you're still around, I see you're using Arch Linux. How comfortable would you be with rebuilding Arch's glvnd package with this patch included?

BTW, this test will only work if Arch actually uses glvnd, but I think it does based on this old news article: https://archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/. Would be helpful to confirm that for certain.

Comment on attachment 464540 [details] Test patch for glvnd Um, the patch is broken. Sec. :)

Created attachment 464541 [details] glvnd debug patch, try #2

(In reply to Michael Catanzaro from comment #22) > BTW, this test will only work if Arch actually uses glvnd, but I think it > does based on this old news article: > https://archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/. > Would be helpful to confirm that for certain. Yes, Arch has been using libglvnd for a good while, and it's the provider chosen by default for the “libgl” virtual package: https://archlinux.org/packages/extra/x86_64/libglvnd/

Can anyone at least confirm the bug still exists?

I've been trying to get some testers for the patch. But it seems like people are expecting some ready to run binaries. Not having to compile or install anything: https://gitlab.com/news-flash/news_flash_gtk/-/issues/318

Alas, for this bug we really do need someone who is comfortable with modifying libglvnd. If using via flatpak, that would require rebuilding the runtime.

Rebuilt libglvnd with patch from Michael. Can confirm issue still present in MiniBrowser example. Running Nvidia 525.85.05 uname -a: Linux party 6.1.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 24 Jan 2023 21:07:04 +0000 x86_64 GNU/Linux Webkit5 installed from repo. ldd shows patched library is being linked. If i should rebuild wk-5.0 from source, it will wait till tomorrow, when i get my new cpu home, because i've got no patience for building on a 4-core machine

No need to build WebKit. That was exactly the testing that we needed. Was hoping you'd say it was fixed, but oh well. Thanks.

(In reply to Michael Catanzaro from comment #30) > No need to build WebKit. That was exactly the testing that we needed. Was > hoping you'd say it was fixed, but oh well. Thanks. If it "just worked"™️ we'd all have no job security ;) feel free to ping me here or on Mastodon cpebble@norrebro.space if you need testing or further debug traces at some point

In case it's helpful, an NVIDIA Tangram user has reported to have washed out colors instead of completely white. https://github.com/sonnyp/Tangram/issues/231

> In case it's helpful, an NVIDIA Tangram user has reported to have washed out colors instead of completely white. I thought this was already known, so I didn't report it. But yes, "dark" content is visible, but way brighter than it should be: https://gitlab.com/news-flash/news_flash_gtk/-/issues/419

That might be worth a separate bug report. I think it's safe to say we don't know anything about problems with NVIDIA except for what you see here in this issue.

Hey! I’m the nvidia tangram user. I’m comfortable compiling for source. What can I do to help?

Hmm, at this time I need to ping our graphics developers again because so far we have all the info they requested. But I'm glad you're here as no doubt we'll need you to test something soon enough. ;)

So bad news, Red Hat decided we'll only support WebKitGTK for nouveau users. We might have some further debugging tips to provide but otherwise won't be working on this after all.

Hey guys, I had a look at this with a debug build of the NVIDIA driver which might help. I tried Michael's suggestion of adding a glFinish() before glX/eglMakeCurrent but that didn't have an effect. For the record I'm using the GTK4 app "newsflash", which includes a WebKit view, and currently that area is completely blank. What seems to be the issue is that the alpha channel of the pixmap that the WebKit process renders to is zero, but the GUI process interprets it as ARGB data. If I hack cairo to always interpret the data as XRGB instead it fixes the problem for me. I'm still not sure whether it's a driver bug or an issue in WebKit, but at least this narrows it down somewhat. The pixmap *is* depth-32 so it's a bit strange that no alpha data is getting written.

Ok. The problem is that while the WebKit process chooses a depth-32 X11 visual for its window (in PlatformDisplayX11::visual), the associated GLXFBConfig doesn't actually have an alpha channel. So it ends up rendering in RGB. It looks like Chromium devs struggled with a similar problem years ago [1]. There's not really a reliable way to choose a suitable X11 visual without calling into GLX, so fixing this might be a bit tricky with the current architecture. Also, a separate issue is that GLContextGLX::createWindowContext includes "GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, GL_FALSE" in its glXChooseFBConfig criteria, which causes that function to fail to find any configs. Is there a reason for doing that? SRGB framebuffers are disabled by default even if the config supports them, so it shouldn't be necessary, right? Regardless, though, even if that criterion is removed, it will find a config but glXMakeCurrent will fail because you can't make an XRGB drawable current to an ARGB context. So the visual thing also needs to be fixed somehow. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=369209

Thanks for looking into this. So I don't understand graphics much, but I do know that we do not depend on GLX anymore -- EGL is mandatory nowadays -- so talk about GLX is a red flag because we're not using that anymore. So I think you've been debugging an older version of WebKitGTK with different graphics architecture? The current stable release is 2.40.0 and the last release to use GLX was 2.38. There's probably no point in debugging 2.38 at this point. (I think the GLX code is still present in 2.40, but unused. In main it has been removed.)

Erik mentioned "newsflash" which is indeed still on the old webkit2gtk-5.0 API. The new API was just released and there are still no rust bindings for it.

I used newsflash because a few of the earlier comments mentioned it. Are we sure that the issue is actually still present with 2.40? I tried the midori browser, which does use 2.40, but that seems to work fine on my system.

(In reply to Erik Kurzinger from comment #42) > Are we sure that the issue is actually still present with 2.40? I'm not sure. I hope we didn't have you doing a wild goose chase. Could someone who is able to reproduce the problem (e.g. cpcp800) please confirm this is still broken with 2.40.0? For reference, we switched from GLX to EGL in https://commits.webkit.org/254751@main (present in 2.40, not in 2.38) and removed the code in https://commits.webkit.org/261741@main (will be present in 2.42, not in 2.40).

Hello. I have the same issue with Epiphany 44.1 flatpak which uses webkit 2.40. My laptop uses the older proprietary nvidia-340 and it was suggested on irc I include webkit://gpu text. Note this page also renders blank, but I can still copy and paste from it. Copy to clipboard Version Information WebKit version WebKitGTK 2.40.0 (tarball) Operating system Linux 5.4.0-146-generic #163~18.04.1-Ubuntu SMP Mon Mar 20 15:02:59 UTC 2023 x86_64 Desktop Enlightenment Cairo version 1.16.0 (build) 1.16.0 (runtime) GStreamer version 1.20.5 (build) GStreamer 1.20.5 (runtime) GTK version 4.10.1 (build) 4.10.1 (runtime) Display Information Type X11 Screen geometry 0,0 1920x1080 Screen work area 0,0 1920x1080 Depth 24 Bits per color component 8 DPI 96 Hardware Acceleration Information Policy always WebGL enabled Yes API OpenGL ES 2 (libepoxy) Native interface GLX GL_RENDERER GeForce GT 330M/PCIe/SSE2 GL_VENDOR NVIDIA Corporation GL_VERSION OpenGL ES 2.0 340.108 GL_SHADING_LANGUAGE_VERSION OpenGL ES GLSL ES 1.00 GL_EXTENSIONS GLX_VERSION 1.4 GLX_VENDOR NVIDIA Corporation GLX_EXTENSIONS GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_EXT_swap_control GLX_EXT_swap_control_tear GLX_EXT_buffer_age GLX_ARB_create_context GLX_ARB_create_context_profile GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_EXT_fbconfig_packed_float GLX_EXT_texture_from_pixmap GLX_EXT_framebuffer_sRGB GLX_NV_present_video GLX_NV_copy_image GLX_NV_multisample_coverage GLX_NV_video_capture GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_ARB_create_context_robustness GLX_NV_delay_before_swap GLX_EXT_stereo_tree

I think we should backport at least the protocol handler changes from 261741@main to 2.40 branch. Since the GLX code is really completely unused in 2.40 (right?) but without that commit, we still print GLX rather than EGL stuff in webkit://gpu, which is not what we need to see here. > OpenGL ES 2 (libepoxy) Hm, OpenGL ES is supposed to be supported and working, but it's pretty unusual for a desktop system, and I bet it's rarely tested....

Terminal output: $ flatpak run org.gnome.Epiphany (epiphany:2): epiphany-WARNING **: 19:18:28.252: Failed to search secrets in password schema: org.freedesktop.DBus.Error.ServiceUnknown Gsk-Message: 19:18:28.468: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkX11Toplevel': Compilation failure in shader. Source Code: 1| #version 100 2| #define GSK_GLES 1 3| #define NO_CLIP 1 4| #ifndef GSK_LEGACY 5| precision highp float; 6| #endif 7| 8| #if defined(GSK_GLES) || defined(GSK_LEGACY) 9| #define _OUT_ varying 10| #define _IN_ varying 11| #define _GSK_ROUNDED_RECT_UNIFORM_ vec4[3] 12| #else 13| #define _OUT_ out 14| #define _IN_ in 15| #define _GSK_ROUNDED_RECT_UNIFORM_ GskRoundedRect 16| #endif 17| 18| 19| struct GskRoundedRect 20| { 21| vec4 bounds; // Top left and bottom right 22| // Look, arrays can't be in structs if you want to return the struct 23| // from a function in gles or whatever. Just kill me. 24| vec4 corner_points1; // xy = top left, zw = top right 25| vec4 corner_points2; // xy = bottom right, zw = bottom left 26| }; 27| 28| // Transform from a C GskRoundedRect to what we need. 29| GskRoundedRect 30| gsk_create_rect(vec4[3] data) 31| { 32| vec4 bounds = vec4(data[0].xy, data[0].xy + data[0].zw); 33| 34| vec4 corner_points1 = vec4(bounds.xy + data[1].xy, 35| bounds.zy + vec2(data[1].zw * vec2(-1, 1))); 36| vec4 corner_points2 = vec4(bounds.zw + (data[2].xy * vec2(-1, -1)), 37| bounds.xw + vec2(data[2].zw * vec2(1, -1))); 38| 39| return GskRoundedRect(bounds, corner_points1, corner_points2); 40| } 41| 42| vec4 43| gsk_get_bounds(vec4[3] data) 44| { 45| return vec4(data[0].xy, data[0].xy + data[0].zw); 46| } 47| 48| vec4 gsk_premultiply(vec4 c) { 49| return vec4(c.rgb * c.a, c.a); 50| } 51| 52| vec4 gsk_scaled_premultiply(vec4 c, float s) { 53| // Fast version of gsk_premultiply(c) * s 54| // 4 muls instead of 7 55| float a = s * c.a; 56| 57| return vec4(c.rgb * a, a); 58| } 59| uniform mat4 u_projection; 60| uniform mat4 u_modelview; 61| uniform float u_alpha; 62| 63| #if defined(GSK_GLES) || defined(GSK_LEGACY) 64| attribute vec2 aPosition; 65| attribute vec2 aUv; 66| attribute vec4 aColor; 67| attribute vec4 aColor2; 68| _OUT_ vec2 vUv; 69| #else 70| _IN_ vec2 aPosition; 71| _IN_ vec2 aUv; 72| _IN_ vec4 aColor; 73| _IN_ vec4 aColor2; 74| _OUT_ vec2 vUv; 75| #endif 76| 77| // amount is: top, right, bottom, left 78| GskRoundedRect 79| gsk_rounded_rect_shrink (GskRoundedRect r, vec4 amount) 80| { 81| vec4 new_bounds = r.bounds + vec4(1.0,1.0,-1.0,-1.0) * amount.wxyz; 82| vec4 new_corner_points1 = r.corner_points1; 83| vec4 new_corner_points2 = r.corner_points2; 84| 85| if (r.corner_points1.xy == r.bounds.xy) new_corner_points1.xy = new_bounds.xy; 86| if (r.corner_points1.zw == r.bounds.zy) new_corner_points1.zw = new_bounds.zy; 87| if (r.corner_points2.xy == r.bounds.zw) new_corner_points2.xy = new_bounds.zw; 88| if (r.corner_points2.zw == r.bounds.xw) new_corner_points2.zw = new_bounds.xw; 89| 90| return GskRoundedRect (new_bounds, new_corner_points1, new_corner_points2); 91| } 92| 93| void 94| gsk_rounded_rect_offset(inout GskRoundedRect r, vec2 offset) 95| { 96| r.bounds.xy += offset; 97| r.bounds.zw += offset; 98| r.corner_points1.xy += offset; 99| r.corner_points1.zw += offset; 100| r.corner_points2.xy += offset; 101| r.corner_points2.zw += offset; 102| } 103| 104| void gsk_rounded_rect_transform(inout GskRoundedRect r, mat4 mat) 105| { 106| r.bounds.xy = (mat * vec4(r.bounds.xy, 0.0, 1.0)).xy; 107| r.bounds.zw = (mat * vec4(r.bounds.zw, 0.0, 1.0)).xy; 108| 109| r.corner_points1.xy = (mat * vec4(r.corner_points1.xy, 0.0, 1.0)).xy; 110| r.corner_points1.zw = (mat * vec4(r.corner_points1.zw, 0.0, 1.0)).xy; 111| 112| r.corner_points2.xy = (mat * vec4(r.corner_points2.xy, 0.0, 1.0)).xy; 113| r.corner_points2.zw = (mat * vec4(r.corner_points2.zw, 0.0, 1.0)).xy; 114| } 115| 116| #if defined(GSK_LEGACY) 117| // Can't have out or inout array parameters... 118| #define gsk_rounded_rect_encode(r, uni) uni[0] = r.bounds; uni[1] = r.corner_points1; uni[2] = r.corner_points2; 119| #else 120| void gsk_rounded_rect_encode(GskRoundedRect r, out _GSK_ROUNDED_RECT_UNIFORM_ out_r) 121| { 122| #if defined(GSK_GLES) 123| out_r[0] = r.bounds; 124| out_r[1] = r.corner_points1; 125| out_r[2] = r.corner_points2; 126| #else 127| out_r = r; 128| #endif 129| } 130| 131| #endif 132| 133| // blend.glsl 134| 135| void main() { 136| gl_Position = u_projection * u_modelview * vec4(aPosition, 0.0, 1.0); 137| 138| vUv = vec2(aUv.x, aUv.y); 139| } 140| 141| // FRAGMENT_SHADER: Error Message: 0(30) : error C7551: OpenGL first class arrays require #version 120 0(43) : error C7551: OpenGL first class arrays require #version 120 0(120) : error C7551: OpenGL first class arrays require #version 120 Cannot create EGL sharing context: error binding OpenGL API (EGL_BAD_PARAMETER) Cannot create EGL sharing context: error binding OpenGL API (EGL_BAD_PARAMETER)

The current devel version if far less verbose; it flat out refuses to run, claiming it needs one of 3 requirements. I apparently meet 2 out of 3. bodhi@VPCF115FM:~$ flatpak run org.gnome.Epiphany.Devel (epiphany:2): epiphany-WARNING **: 20:13:12.716: Failed to search secrets in password schema: org.freedesktop.DBus.Error.ServiceUnknown No provider of glGenSamplers found. Requires one of: Desktop OpenGL 3.3 GL_ARB_sampler_objects OpenGL ES 3.0 bodhi@VPCF115FM:~$ glxinfo|grep "OpenGL version" OpenGL version string: 3.3.0 NVIDIA 340.108 bodhi@VPCF115FM:~$ glxinfo|grep GL_ARB_sampler_objects GL_ARB_sample_shading, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, GL_ARB_sample_shading, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, bodhi@VPCF115FM:~$ glxinfo|grep "OpenGL ES profile version" OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 340.108 340.108 bodhi@VPCF115FM:~$

(In reply to Craig from comment #47) > The current devel version if far less verbose; it flat out refuses to run, > claiming it needs one of 3 requirements. I apparently meet 2 out of 3. After discussing this with Benjamin, it looks like this is actually required by GTK 4, not by WebKit. Are you able to run any other GTK 4 applications?

(In reply to Michael Catanzaro from comment #48) > After discussing this with Benjamin, it looks like this is actually required > by GTK 4, not by WebKit. Are you able to run any other GTK 4 applications? I am using an older distro and don't believe I have anything GTK4 already, so I installed gnome-calculator flatpak from gnome-nightly to test, and indeed it fails with the same error. $ flatpak run org.gnome.Calculator.Devel No provider of glGenSamplers found. Requires one of: Desktop OpenGL 3.3 GL_ARB_sampler_objects OpenGL ES 3.0 $

Craig reported https://gitlab.gnome.org/GNOME/gtk/-/issues/5858 since that is indeed a problem with using any GTK 4 apps.

Hello, I have a report from an nVidia user that says that WebKitGTK 2.40.3 works fine but after upgrading to 2.41.6 it stops working (but only the GTK3 builds). This is all with Debian unstable on an X11 GNOME session: - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.0. its MiniBrowser stops working. WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.1. its MiniBrowser stops working. WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again - (2.41.5-1 => 2.41.6-1) for webkitgtk-6.0. its MiniBrowser still works. GPU: GTX 970, Maxwell architecture nvidia-driver 530 Some more details here: https://gist.github.com/awfulcooking/70958c36d86b30e6d00d2894bcfa7bb1

*** Bug 259644 has been marked as a duplicate of this bug. ***

(In reply to Alberto Garcia from comment #51) > Hello, > > I have a report from an nVidia user that says that WebKitGTK 2.40.3 works > fine but after upgrading to 2.41.6 it stops working (but only the GTK3 > builds). > > This is all with Debian unstable on an X11 GNOME session: > > - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.0. its MiniBrowser stops working. > WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again > - (2.40.3-2 => 2.41.6-1) for webkit2gtk-4.1. its MiniBrowser stops working. > WEBKIT_DISABLE_COMPOSITING_MODE=1 makes it work again > - (2.41.5-1 => 2.41.6-1) for webkitgtk-6.0. its MiniBrowser still works. > > GPU: GTX 970, Maxwell architecture > nvidia-driver 530 > > Some more details here: > > https://gist.github.com/awfulcooking/70958c36d86b30e6d00d2894bcfa7bb1 This user has a different bug that will need to be reported separately.

In my case, WebKitGTK 2.40.x works correctly without any issue. It is only with WebKitGTK 2.41.x that I get a blank screen. I can corroborate that web pages seem to be rendered but not shown, and dragging items of the page generate a thumbnail that follows my cursor as expected. Moreover, disabling DMABUF causes the web view to show the correctly rendered page, but the tab hangs quickly after.

Copied over from the duplicate bug, my setup is the following: Tested with: Epiphany Technology Preview/ WebKitGTK 2.41.6; Nvidia RTX 4070 (driver version 535, via Universal Blue Nvidia Image) No web view is rendered. Blank screen. Console output: [kdwk@fedora ~]$ flatpak run org.gnome.Epiphany.Devel KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1148x893: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1148x893: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1148x893: Permission denied Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 [reply] [−] Comment 1

Hi, seems like I'm a bit late to the party, but anyways ... I recently reported a bug against liferea (a GTK3 based RSS reader using WebkitGTK as an HTML rendering engine), where the HTML preview frame would appear empty with the newly released webkitgtk-2.42.0, while with webkitgtk-2.40.5 (and all previous webkitgtk versions) the preview frame would be rendered "normally" (ie. as expected). The devs asked me if I had an Nvidia GPU, and if the problem would disappear if I ran liferea with WEBKIT_DISABLE_COMPOSITING_MODE=1. I do and it did, so they directed me over here. Here's a link to my bug report, which also includes screenshots: https://github.com/lwindolf/liferea/issues/1306 Is this the same bug that is being discussed here? If not, should I open a new bug report, or is there already an existing one that I could follow? Please let me know. Thanks!

(In reply to Thomas Zajic from comment #56) > Is this the same bug that is being discussed here? No, because the problem here is specific to GTK 4 and has been around for years. That is, since you didn't have this problem with 2.40, this bug is not your bug. You're probably hitting either bug #259644 or bug #261874, depending on whether or not you see those KMS DRM_IOCTL_MODE_CREATE_DUMB error messages. Please confirm. (In reply to Kdwk from comment #55) > Copied over from the duplicate bug, my setup is the following: > > Tested with: Epiphany Technology Preview/ WebKitGTK 2.41.6; Nvidia RTX 4070 > (driver version 535, via Universal Blue Nvidia Image) > > No web view is rendered. Blank screen. > > Console output: > [kdwk@fedora ~]$ flatpak run org.gnome.Epiphany.Devel > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 1148x893: Permission denied > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 1148x893: Permission denied > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 1148x893: Permission denied > Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 > [reply] [−] Comment 1 This issue is now tracked in bug #259644.

(In reply to Michael Catanzaro from comment #57) > (In reply to Thomas Zajic from comment #56) > > Is this the same bug that is being discussed here? > > No, because the problem here is specific to GTK 4 and has been around for > years. That is, since you didn't have this problem with 2.40, this bug is > not your bug. > > You're probably hitting either bug #259644 or bug #261874, depending on > whether or not you see those KMS DRM_IOCTL_MODE_CREATE_DUMB error messages. > Please confirm. I'm not using modesetting (KMS), I'm not using flatpak, and I don't see those error messages in any of my logs. So, which of the two "alternative bugs" is "mine"? :-) Thanks, Thomas

Here's my copy/paste of webkit://gpu, in case that matters. Note that I'm currenty setting "WEBKIT_DISABLE_COMPOSITING_MODE=1" globally from /etc/profile, to work around the rendering bug in liferea. { "Version Information": { "WebKit version": "WebKitGTK 2.42.0 (tarball)", "Operating system": "Linux 6.1.54 #1 SMP PREEMPT_DYNAMIC Tue Sep 19 15:59:34 CEST 2023 x86_64", "Desktop": "GNOME-Flashback:GNOME", "Cairo version": "1.16.0 (build) 1.16.0 (runtime)", "GStreamer version": "1.22.5 (build) GStreamer 1.22.6 (runtime)", "GTK version": "4.12.1 (build) 4.12.2 (runtime)" }, "Display Information": { "Type": "X11", "Screen geometry": "1920,0 1920x1080", "Screen work area": "1920,28 1920x1020", "Depth": "24", "Bits per color component": "8", "DPI": "96" }, "Hardware Acceleration Information": { "Policy": "never", "WebGL enabled": "Yes" } }

I could not reproduce this with NVIDIA RTX 4060, tested with the following configurations: * Wayland, Nouveau, WebKitGTK from main * Wayland, Nouveau, WebKitGTK 2.42.5 * Wayland, proprietary driver, WebKitGTK from main * Wayland, proprietary driver, WebKitGTK 2.42.5 * X11, Nouveau, WebKitGTK from main * X11, Nouveau, WebKitGTK 2.42.5 * X11, proprietary driver, WebKitGTK from main * X11, proprietary driver, WebKitGTK 2.42.5 I have not tested the GTK3 build. Will test with an old Kepler card on an ancient laptop I have

After Sonny reached out on Mastodon, people reported a variety of problems that were either tracked down to misconfigured systems (e.g. missing NVIDIA GBM, no modesetting, etc), and the cases that did look like interesting cases seemed to be fixed with WebKitGTK 2.42.5. I think it's reasonable to assume this bug was fixed by the combination of the various refactorings to DMA-BUF handling code in WebKitGTK, and newer NVIDIA cards. If anyone can reproduce reproduce this with a modern version (2.42+) of WebKitGTK GTK4, please speak up and the issue can be reopened. But please make sure to read https://bugs.webkit.org/show_bug.cgi?id=261874#c32 and see if your issue is not described in that comment.

Hi Craig and Thomas (and Emil if you're still around): if you're still encountering problems with NVIDIA graphics, please report new a bug and leave a comment here linking to the new bug.

Hi Michael, I already hopped over to bug #261874, as the description in #c32 over there matches my setup exactly. The errors I get are: > [zlatko@disclosure:~]$ liferea > src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) > > Failed to create GBM buffer of size 469x191: Invalid argument > src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) > >Failed to create GBM buffer of size 469x191: Invalid argument > src/nv_gbm.c:99: GBM-DRV error (nv_gbm_bo_create): DRM_IOCTL_NVIDIA_GEM_ALLOC_NVKMS_MEMORY failed (ret=-1) > > Failed to create GBM buffer of size 469x191: Invalid argument > Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 Yes, I'm on X11 without modsetting (with NVidia this only works when booting UEFI, which I don't), and "liferea" is a GTK3 application (ie. using libwebkit2gtk-4.0.so), where the current state still seems to be ... > "There's no workaround for GTK3, we need to figure out why gbm_bo_map is failing and fix it." ... so this bug seems to be the perfect fit. :-)

This bug is for GTK4, Liferea is GTK3. That's a separate issue that should not be marked as a blocker for https://bugs.webkit.org/show_bug.cgi?id=210100

(In reply to Michael Catanzaro from comment #62) > Hi Craig and Thomas (and Emil if you're still around): if you're still > encountering problems with NVIDIA graphics, please report new a bug and > leave a comment here linking to the new bug. My problem was on legacy nvidia driver, and newer versions wouldn't even start. But I now know a workaround (GSK_RENDERER=cairo) and don't expect there will be a fix for my old driver anyway. https://gitlab.gnome.org/GNOME/gtk/-/issues/5858