Did some digging and found this bug report originating from Fedora for yelp, which fails in the same manner as mcc over ssh in Cauldron:
https://bugs.webkit.org/show_bug.cgi?id=259320

The bug report points to an issue with the mesa llvmpipe driver, the driver that is used for rendering over ssh. 

# inxi -Gx # over ssh
Graphics:
  Device-1: AMD Navi 23 [Radeon RX 6600/6600 XT/6600M] vendor: Sapphire
    driver: amdgpu v: kernel arch: RDNA-2 bus-ID: 0d:00.0
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: amdgpu,v4l dri: swrast gpu: amdgpu s-res: 3840x1200 resolution:
    1: 1920x1200 2: 1920x1200
  API: OpenGL v: 4.5 Mesa 23.1.5 renderer: llvmpipe (LLVM 15.0.6 256 bits)
    direct-render: Yes

Thank you for the report, and that Fedora link which does indeed look similar.
"REGRESSION(2.41.6): [GTK] Yelp help viewer and Epiphany browser do not show content on a virtual machine (llvmpipe?) with WebKitGTK 2.41.6"
It is very recnt: 2023-07-18 - 2023-07-21
It points to webkit: https://commits.webkit.org/266201@main
The patch is shown here:
https://github.com/WebKit/WebKit/commit/ad44d7bf323c78bd79f184859afb65d107efb103

No one person nurses webkit2, so assigning this globally; CC'ing NicolasS & DavidG who have most recently committed it.

URL: (none) => https://bugs.webkit.org/show_bug.cgi?id=259320
Assignee: bugsquad => pkg-bugs
CC: (none) => geiger.david68210, nicolas.salguero

Bug 30332 is also about drakconf missing display elements after an earlier update to webkit2 (>=2.36); this bug applies to >=2.41.6. Upping the importance because of its multiple occurrence; do not think it is a duplicate.

Severity: normal => major

https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools

also see todays note in Bug 30332

CC: (none) => fri
Keywords: (none) => IN_ERRATA9

Not only over ssh.

See me in Bug 30332#c42 and
https://forums.mageia.org/en/viewtopic.php?f=7&t=15031
and I think I also saw it in a mail list.

Summary: webkit2: drakconf (mcc) over ssh fails to display its menu options on the right hand side. => webkit2: drakconf (mcc) local and over ssh fails to display its icons on the right hand side.

Hello,
I'm seeing the bug on a RASPBERRY PI 4B using modesetting as graphical driver, thus on aarch64.
All tabs of MCC are blank and inactive.

CC: (none) => yvesbrungard

I have found that while it most often works OK, it may fail several times in a try repeatedly.  If i then close other application (s) such as firefox, MCC then works OK.  So: Something about resources?

(In reply to Morgan Leijström from comment #7)
> I have found that while it most often works OK, it may fail several times in
> a try repeatedly.  If i then close other application (s) such as firefox,
> MCC then works OK.  So: Something about resources?
I have not seen the behavior you mentioned on my system.

However, as you mentioned resources, I tried IceWM with the same results as in the initial report, but, for my surprise, under Plasma - XWayland everything looks peachy. BTW, my initial report was carried out in Plasma - X11, sorry, it does look like I missed to mention it.
Regards.

Someone reported another case of missing icons, though with a different log, on dev mailing list:

https://ml.mageia.org/l/arc/dev/2023-10/msg00072.html

CC: (none) => animtim

I have a similar issue: 

I have a freshly installed M9 upgraded to Cauldron based machine - and recently, when I tried to start the MCC, I get the interface but without icons (just the menu on the side)  -  I tried to de-install and re-install, but that didn't help - looking at the console where I started it - I see some errors related to GBM-Drv - Maybe something to do with the proprietary NVidia drivers?

[rfox@FoxLT5 ~]$ sudo mcc
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_DE:de",
        LC_ALL = (unset),
        LC_ADDRESS = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_PAPER = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_SOURCED = "1",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LANG = "en_DE"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.

(process:50513): Gtk-WARNING **: 09:58:00.799: Locale not supported by C library.
        Using the fallback 'C' locale.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_DE:de",
        LC_ALL = (unset),
        LC_MONETARY = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LANG = "en_DE"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Ignore the following Glib::Object::Introspection & Gtk3 warnings

(process:50514): Gtk-WARNING **: 09:58:00.956: Locale not supported by C library.
        Using the fallback 'C' locale.
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
"cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833.

(process:50555): Gtk-WARNING **: 09:58:01.483: Locale not supported by C library.
        Using the fallback 'C' locale.
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
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 1513x1201: 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 1513x1201: 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 1513x1201: Invalid argument
Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1

CC: (none) => rfox

Created attachment 14068 [details]
screenshot of mcc

Hi,

I've got a similar issue.
serveur = PC running mageia9, using xfce as Desktop gui and intel (Intel 810 and later) driver.
local = PC running mageia9, using Plasma as Desktop gui and nvidia (NVIDIA GeForce 635 to GeForce 920) driver.
From my local PC , I connect with ssh to the server one.
# ssh serveur
# su -l root
# mcc&

Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.

(mcc:332412): dbind-WARNING **: 18:43:28.155: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Ignore the following Glib::Object::Introspection & Gtk3 warnings

(drakconf:332418): dbind-WARNING **: 18:43:28.515: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
"cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833.
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
libEGL warning: DRI2: failed to authenticate

(WebKitWebProcess:332456): Gdk-WARNING **: 18:43:29.279: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 169 error_code 1 request_code 154 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I do not have any icons on the right hand-side of the mcc window (see the above attachment of Robert Fox).

Server :
# rpm -qa | grep webkit2
webkit2-driver-2.40.3-1.mga9
lib64webkit2gtk4.1_0-2.40.3-1.mga9
webkit2gtk4.1-2.40.3-1.mga9
lib64webkit2gtk4.0_37-2.40.3-1.mga9
webkit2gtk4.0-2.40.3-1.mga9
lib64webkit2gtk-gir4.1-2.40.3-1.mga9
lib64webkit2gtk-gir4.0-2.40.3-1.mga9

local :
# rpm -qa | grep webkit2
webkit2-driver-2.40.3-1.mga9
webkit2gtk4.1-2.40.3-1.mga9
lib64webkit2gtk4.1_0-2.40.3-1.mga9
lib64webkit2gtk-gir4.1-2.40.3-1.mga9

I didn't try to downgrade the webkit2 packages (too risky to me :)).
Do you have any new ideas to fix this issue ?

Regards.

Xuo.

CC: (none) => xuoy

Hi,

Closing all other local applications (local mcc, Firefox, Thunderbird, ... except the Konsole terminal) didn't improve anything.

Regards.

Xuo.

Today, I got a similar but different behaviour.
I started mcc from a root console. All was fine.
But starting again, right panel is blank AND tabs are inactive. Until now, the tabs were active.
Starting again with no success, from console or from menu with polkit dialogue.
Intel graphic card.

Missing icons in MCC on M9 with nVidea graphics issue - my fix: https://bugs.mageia.org/show_bug.cgi?id=30332#c47

CC: (none) => playthatbeat

This issue with icons being invisibe sometimes hit here. I can usually click the white space where they should be and the intended tool do launch.

But today for me this new experience nothing can be clicked at, mouse pointer is always an arrow any place in the white area and nothing happens when i click.

Fully updated Mageia 9 incl testing, nvidia535 on GTX750, but booted elder kernel-desktop-6.4.16-3.mga9.x86_64, Plasma.

Continuation of Comment 16:

Starting it as root in konsole, no icon visible nor clickable:

[root@svarten ~]# mcc
Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
EGLDisplay Initialization failed: EGL_BAD_ACCESS
Cannot create EGL sharing context: invalid display (last error: EGL_SUCCESS)

(WebKitWebProcess:1428332): Gdk-WARNING **: 12:24:18.036: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 207 error_code 2 request_code 152 (GLX) minor_code 34)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

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

CC: (none) => pascal

We need to get this squashed!

This system had this problem there in mga8, Bug 30332 Comment 27.
I also now tested it after full mga8 update, problem is there unless packages downdated per description. (and put in skip list)

Now upgraded the system to mga9:
(fully, nothing in skip.list), Bug 32985#c45
And the problem is visible when launching MCC but icons appear immediately when i resize the window. And sometime I only have to let mouse pointer move over it.

Whiteboard: (none) => MGA9TOO
Priority: Normal => High

Please note that in mga9 (not Cauldron), on this date and when fully updated, when using a GTX 750 Ti, this problem occurs when the NVidia New Feature driver is used (driver 545.*) and goes away when the NVidia Production driver (x11-driver-video-nvidia-current-550.54.14-2.mga9.nonfree).  In this instance, there is no need to down-grade webkit.

CC: (none) => kbulgrien

I had this problem randomly even on successive launches in same session, i.e:

1) Launch MCC: no icons
 - keep the first MCC up and directly:
2) Launch another another MCC: OK !

So it varies even with no system change, and in this case obviously no problem of missing resources as it worked better launching the second instance...

Maybe something is randomly executed in wrong order, some kind of sequence interlock need be added?


Anyway, now we have recently released new X11, mesa, kernels, and nvidia-current, and I see a new webkit in updates_testing.

Is it by chance any better?

Created attachment 14513 [details]
spec file for waypipe

Mageia 9( with up to date "update-testing" repos ) and Cauldron, they both show some regression as the mcc window closes almost immediately now with almost identical error message. This is happening under Plasma X11 while under Plasma XWayland/Wayland everything is fine. BTW, the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 doesn't help.

As a workaround, avoiding X11 and using Wayland only, one can use "waypipe" which is not yet packaged for Mageia, but can be easily done(attached is a spec file for it).  

waypipe:
https://gitlab.freedesktop.org/mstoeckl/waypipe/

redhat docs:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment

The problem seen when running over ssh is most likely not the same as the problem seen when running locally. I can reliably reproduce the problem over ssh, but have never managed to reproduce the problem running locally.

When testing workarounds that set environment variables, it is important to know that /usr/bin/mcc is a soft link to /usr/bin/drakconf, which in turn is a wrapper script that runs /usr/libexec/drakconf via pkexec, and that pkexec unsets all but a handful of essential environment variables. So test like this (as root):

  WEBKIT_DISABLE_COMPOSITING_MODE=1 /usr/libexec/drakconf

This fixes the problem when running over ssh for me.

For people experiencing the problem when running locally, you could also try

  WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf

CC: (none) => mageia

Only trying locally, with the updated webkit, drakconf aborts with:
 
WARNING **: Failed to load shared library 'libwebkit2gtk-4.1.so.0' referenced by the typelib: /lib64/libwebkit2gtk-4.1.so.0: undefined symbol: _ZN3JSC14JSGlobalObject14deletePropertyEPNS_6JSCellEPS0_NS_12PropertyNameERNS_18DeletePropertySlotE at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 110.

Doh, I had forgot the lib64javascriptcore packages!

Prior to the webkit update, I launched five instances of mcc with no problem; icons visible.

But after the update, several tries never the icons visible...

Looking in launching terminal:

$ LC_ALL=C sudo /usr/libexec/drakconf
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223.
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 890x776: Permission denied
* and icons are invisible (but works to click where they should be)


But using the suggestion from Martin:
$ LC_ALL=C sudo WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf
-give same output as above minus the two last lines
*and icons are visible*


(note that drakconf need be launched as root / using sudo)

(In reply to Martin Whitaker from comment #23)
Never run into this kind of issues locally. I can only reproduce this bug over ssh with X11 only. 
WEBKIT_DISABLE_DMABUF_RENDERER=1 it never did any good with ssh for my tests, but it did help with mcc when running in a VirtualBox.

(In reply to Morgan Leijström from comment #25)
> Doh, I had forgot the lib64javascriptcore packages!
> 
> Prior to the webkit update, I launched five instances of mcc with no
> problem; icons visible.
> 
> But after the update, several tries never the icons visible...
> 
> Looking in launching terminal:
> 
> $ LC_ALL=C sudo /usr/libexec/drakconf
> Ignore the following Glib::Object::Introspection & Gtk3 warnings
> Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line
> 539.
> GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion
> 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line
> 223.
> GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion
> 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line
> 223.
> GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion
> 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line
> 223.
> GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion
> 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line
> 223.
> Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want
> WebKit to use a different signal
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 890x776: Permission denied
> * and icons are invisible (but works to click where they should be)
> 
> 
> But using the suggestion from Martin:
> $ LC_ALL=C sudo WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/libexec/drakconf
> -give same output as above minus the two last lines
> *and icons are visible*
> 
> 
> (note that drakconf need be launched as root / using sudo)

I suggest add this to erratas (if not already in) until devs make a fix

Please test drakconf-13.29-1.1.mga9 from core/updates_testing when it reaches the mirrors. This sets the two environment variables for you.

That fix works here :)
Local use (not tried ssh)

After updating to new webkit in testing, drakconf always came up without icons for a bout twenty tries.

Now after drakconf update, drakconf always shows icons.

---

Updated https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools

---

In retrospect, the issue is not bound to webkit alone; webkit is just one of many ingredients of the cause.

We need one bug to be set against drakconf to handle this update.
(file list, advisory)
Open a new bug or convert this one?

I will open a new bug for QA.

(In reply to Martin Whitaker from comment #28)
> Please test drakconf-13.29-1.1.mga9 from core/updates_testing when it
> reaches the mirrors. This sets the two environment variables for you.

drakconf-13.29-1.1.mga9 didn't help with running mcc/drakconf over ssh in my case but it does work better locally, without ssh, in a VirtualBox and I haven't noticed any regressions.

Hi everyone.  I ran into this issue almost immediately after installing the latest updates.  I'm glad this bug report was here already.

In my case (locally on X11 with nouveau) either of Martin's two environment variables from Comment 23 seem to work equally well.  Wondering what the difference between them is, I did a bit of searching on the 'Net and soon came across the blog of WebKit developer Carlos Garcia Campos.

From his entry dated a year ago this month, it appears (at least to me) that the DMABUF switch is meant to supersede/replace the COMPOSITING one such that applying both shouldn't be necessary (?).  Specifically he hints that the DMABUF one should alleviate the need to account for the myriad factors brought on by users' disparate setups.

Full blog post is here:  https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/

Quoting the relevant section:

=== CARLOS GARCIA CAMPOS on 2023-04-03 ===

Reducing all the combinations to (almost) one: DMABUF

All these combinations to support the different platforms made it quite difficult to maintain, every time we get a bug report about something not working in accelerated compositing mode we have to figure out the combination actually used by the reporter, GTK3 or GTK4? X11 or Wayland? using EGL or GLX? custom Wayland compositor or libwpe? driver? version? etc.

We are already using DMABUF in WebKit for different things like WebGL and media rendering, so we thought that we could also use it for sharing the rendered buffer between the web and UI processes. That would be a more efficient solution but it would also drastically reduce the amount of combinations to maintain. The web process always uses the surfaceless platform, so it doesn’t matter if it’s under Wayland or X11. Then we create a surfaceless context as the render target and use EGL and GBM APIs to export the contents as a DMABUF buffer. The UI process imports the DMABUF buffer using EGL and GBM too, to be passed to GTK as a texture that is painted in the web view.

This theoretically recudes all the previous combinations to just one (note that we removed GLX support entirely, making EGL a requirement for accelerated compositing), but there’s a problem under X11: GTK3 doesn’t support EGL on X11 and GTK4 defaults to EGL but falls back to GLX if it doesn’t find an EGL config that perfectly matches the screen visual. In my system it never finds that EGL config because mesa doesn’t expose any 32 bit depth config. So, in the case of GTK3 we have to manually download the buffer to CPU and paint normally using Cairo, but in the case of GTK4 + GLX, GTK uploads the buffer again to be painted using GLX. I don’t think it’s possible to force GTK to use EGL from the API, but at least you can use GDK_DEBUG=gl-egl.

=== END QUOTE ===


So, yeah, I'm not sure including both variables makes any difference.  I hope the above info helps in some way.

CC: (none) => johnltw

MGA9-64 Plasma, i5-7500, Nvidia Quadro K620, using nvidia-current.

I hit this bug this morning after receiving the latest webkit2 update. Prior to this, this system had been unaffected. Updating drakconf and drakconf-icons made the symptoms go away.

CC: (none) => andrewsfarm

(In reply to John L. ten Wolde from comment #32)
> So, yeah, I'm not sure including both variables makes any difference.  I
> hope the above info helps in some way.

For me, WEBKIT_DISABLE_COMPOSITING_MODE=1 fixes the bug when connecting over ssh, whereas WEBKIT_DISABLE_DMABUF_RENDERER=1 does not.

Over ssh, none of the 2 settings, by themselves or together, works for me, but I only have a discrete AMD and some dated integrated Intel graphics cards(i915) to test on. This is happening on up to date Mageia 9 and Cauldron and only, as I mentioned before, while running X11.

On two of four tested systems, the problem of missing icons in drakconf showed up firmly (same several tries) after the today released webkit update.

Graphics divers in use are nvidia470 and Xorg modesetting.

The drakconf in testing fixes the problem firmly.

It seems we need to get this drakconf as is out ASAP to aid users
Eventual optimised solution later

Packages in 9/core/updates_testing

########################################
drakconf-13.29-1.1.mga9.noarch.rpm
drakconf-icons-13.29-1.1.mga9.noarch.rpm

SRPM:
drakconf-13.29-1.1.mga9.src.rpm

Assignee: pkg-bugs => qa-bugs
Whiteboard: MGA9TOO => (none)
Version: Cauldron => 9

Based on the different experiences everyone's describing, so much for Carlos' one-size-fits-all solution...

I still have two more systems to upgrade myself.  Both are AMD.  One is an ancient 32-bit machine, the other a newish 64-bit.  I'll comment back later with how they react to either one or both variables.  Like I said earlier though, this 64-bit machine, on X11 with nouveau, works fine locally using either.  I'm not in a position to need ssh.


(In reply to Morgan Leijström from comment #36)
> It seems we need to get this drakconf as is out ASAP to aid users
> Eventual optimised solution later
I have yet to find a clear definition that satisfies my curiosity about the actual differences between the two variables, except that (obviously) DISABLE_COMPOSITING_MODE should do what it says by using a sledge hammer.
But continuing my search, I did end up back on Carlos' blog again, so regarding a more long-term optimised solution... quite an old entry, but perhaps this?

=== CARLOS GARCIA CAMPOS on 2017-03-20 ===

The WebKitGTK+ API is quite complete now, but there’s always new things required by our users.

HARDWARE ACCELERATION POLICY

Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16.

=== END QUOTE ===

Complete blog entry:  https://blogs.igalia.com/carlosgc/2017/03/20/webkitgtk-2-16/

The embedded link to the API he provides has gone 404, but I think I found it now hosted on Valadoc.org.  I'm guessing his link led to one or the other of these two:

https://valadoc.org/webkit2gtk-4.0/WebKit.HardwareAccelerationPolicy.html
https://valadoc.org/webkit2gtk-4.0/WebKit.Settings.hardware_acceleration_policy.html

For additional giggles on this topic, it seems Michael Catanzaro saw trouble brewing on the horizon as far back as January 2019 when he filed an upstream bug report suggesting WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER be made the default going forward.  Carlos quickly put the kybosh on this idea.

See:  https://bugs.webkit.org/show_bug.cgi?id=193972

RH mageia 9 x86_64

LC_ALL=C urpmi --auto --auto-update
medium "QA Testing (32-bit)" is up-to-date
medium "QA Testing (64-bit)" is up-to-date
medium "Core Release (distrib1)" is up-to-date
medium "Core Updates (distrib3)" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date
medium "Core 32bit Release (distrib31)" is up-to-date
medium "Core 32bit Updates (distrib32)" is up-to-date
medium "Nonfree 32bit Release (distrib36)" is up-to-date
medium "Tainted 32bit Release (distrib41)" is up-to-date


installing drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm from //home/katnatek/qa-testing/x86_64
Preparing...                     ##################################################################################################
      1/2: drakconf-icons        ##################################################################################################
      2/2: drakconf              ##################################################################################################
      1/2: removing drakconf-13.29-1.mga9.noarch
                                 ##################################################################################################
      2/2: removing drakconf-icons-13.29-1.mga9.noarch
                                 ##################################################################################################

mcc star without issues from root terminal and icon in panel

RH mageia 9 i586

LC_ALL=C urpmi --auto --auto-update 
medium "QA Testing (32-bit)" is up-to-date
medium "Core Release (distrib1)" is up-to-date
medium "Core Updates (distrib3)" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date

installing drakconf-13.29-1.1.mga9.noarch.rpm drakconf-icons-13.29-1.1.mga9.noarch.rpm from //home/katnatek/qa-testing/i586
Preparing...                     ################################################################
      1/2: drakconf-icons        ################################################################
      2/2: drakconf              ################################################################
      1/2: removing drakconf-13.29-1.mga9.noarch
                                 ################################################################
      2/2: removing drakconf-icons-13.29-1.mga9.noarch
                                 ################################################################

mcc start without issues fro root terminal and icon in panel

About the origina issue I can't say if is fixed or not
I cant start mcc from a ssh connection in any of my systems

This is wat I see conecting from x86_64 system to i586

 mcc
Too late to run INIT block at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.

(mcc:14452): dbind-WARNING **: 19:30:49.920: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Ignore the following Glib::Object::Introspection & Gtk3 warnings

(drakconf:14454): dbind-WARNING **: 19:30:51.000: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223.
GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib/perl5/DynaLoader.pm line 223.
"cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 841.
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI3: failed to query the version
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
MESA: error: ZINK: failed to choose pdev
libEGL warning: egl: failed to create dri2 screen

(drakconf:14454): Gdk-WARNING **: 19:30:55.197: The program 'drakconf' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 618 error_code 1 request_code 155 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

This was tested before and after the update, could be a configuration issue or something else but is not for this bug

(In reply to katnatek from comment #41)
> About the origina issue I can't say if is fixed or not
> I cant start mcc from a ssh connection in any of my systems

It looks like this bug, try "drakrpm" over ssh and, if it works, most likely you hit this bug. Also try wayland environment as I never run into any issues if the local host is running under wayland.

Testing steps:
grep -r "FowardX11" /etc/ssh/ssh_config*  ## to check if set to yes
ssh -X 127.0.0.1
su -
mcc or drakrpm


OTOH, this bug can be reproduced with Fedora Rawhide running in a VirtualBox under Plasma X11 environment, under wayland this doesn't happen. I cannot reproduce the bug if local host is running under Wayland, maybe someone can say otherwise but it looks like it is confined to X11 environment.

I have opened a new bug for QA. This bug shouldn't be closed until the original problem (running remotely over ssh) is fixed. As I commented earlier, we are almost certainly dealing with multiple issues here.

With the latest updates I can now reproduce the bug when running locally in VirtualBox (using the vmware DDX driver and vmwgfx kernel driver). I note that the icons are displayed the first time you run drakconf after booting the machine, but not when switching tabs or when rerunning drakconf. Restarting the X server doesn't help, rebooting the machine does.

I see exactly the same error messages as Aurelian and katnatek report when connecting via ssh, so don't know why the workaround works for me and not for them.

Assignee: qa-bugs => mageiatools

Further note: after installing the webkit2gtk4.1-2.44.2-1.mga9 update, I again see the bug when running over ssh (even with WEBKIT_DISABLE_COMPOSITING_MODE=1). Downgrading to the previous version of webkit2gtk4.1 restores the fix.

Hi
The blank windows of MCC reappeared suddenly for me after a bunch of last updates (kernel nvidia webkit)
I could correct it with :
drakconf-13.29-1.1.mga9.noarch.rpm
drakconf-icons-13.29-1.1.mga9.noarch.rpm

from core-updates-testing repo

This update is efficient and necessary
MGA9 86-64 OK for me

CC: (none) => philippedidier

applied update that included:

  lib64webkit2gtk-gir4.1         2.44.1       1.mga9        x86_64  
  lib64webkit2gtk4.1_0           2.44.1       1.mga9        x86_64  
  lib64webkitgtk6.0_4            2.44.1       1.mga9        x86_64  
  webkit2-driver                 2.44.1       1.mga9        x86_64  
  webkit2gtk4.1                  2.44.1       1.mga9        x86_64  
  webkitgtk6.0                   2.44.1       1.mga9        x86_64

unusual final comment, never had this before.... 

    15/21: removing webkit2-driver-2.40.3-1.mga9.x86_64
                                 #############
    16/21: removing lib64javascriptcoregtk4.1_0-2.40.3-1.mga9.x86_64
                                 #############
    17/21: removing thunderbird-0:115.9.0-1.mga9.x86_64
                                 #############
    18/21: removing lib64jasper6-3.0.6-1.mga9.x86_64
                                 #############
    19/21: removing lib64editorconfig0-0.12.6-1.mga9.x86_64
                                 #############
    20/21: removing nscd-6:2.36-52.mga9.x86_64
                                 #############
    21/21: removing timezone-6:2023c-1.mga9.x86_64
                                 #############
Segmentation fault (core dumped)

Checking mcc via CLI from root - ok, ok from menu and panel launchers.

Graphics:
  Device-1: AMD RV710/M92 [Mobility Radeon HD 4530/4570/5145/530v/540v/545v]
    vendor: Toshiba driver: radeon v: kernel arch: TeraScale pcie:

  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9
    compositor: kwin_x11 driver: X: loaded: radeon,v4l dri: r600 gpu: radeon
    display-ID: :0 screens: 1

System:
  Kernel: 6.6.22-desktop-1.mga9 arch: x86_64 bits: 64 compiler: gcc v: 12.3.0
    Console: pty pts/0 wm: kwin_x11 DM: 1: LightDM note: stopped 2: LXDM
    note: stopped 3: SDDM Distro: Mageia 9

CC: (none) => westel

Alright, I've checked on the two AMD boxes, and within the local context neither are affected by this issue.  The 20-year-old 32-bit machine uses the old ati driver and the newer 64-bit uses radeon.  So yeah, only my old Nvidia (NV96 GeForce) machine running on nouveau needs the environment workaround.

Sorry I can't help at all with testing over ssh.