Blank window after start up - not linked to sse42

[Bilb]

Same issue here.

Not sure it's related, but I just migrated from Ubuntu 24.04 to 25.10 (same machine, same AppImage and same session profile).
Session worked a few times but after recieving a random picture as attachment it crashed witih solid background window. Same errors in the log:

{"level":50,"time":"2025-09-18T20:14:09.563Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-18T20:14:14.569Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-18T20:14:18.136Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-18T20:14:19.574Z","msg":"Error sending from webFrameMain:  {}"}

I tried versions from 1.16.6->1.16.8.
After wiping local profile it works for some time and then starts to blank the screen a few seconds after start-up.

P.S.
My CPU does support sse4_2 and I never had issues with attachments in the past.

Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust sgx bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities

Originally posted by @eugenesan in #1586

[slrslr]

I have this problem too (Unsupported CPU, does not support SSE 4.2 instructions) on Linux Debian (stable - Trixie) with KDE desktop, AppImage: Session 1.16.9 fails to launch. 1.16.8 works.

CPU details are here. I do not have an ancient CPU, so this looks like a bug or a wrong developer decision.

[vidasok801]

This just started happening to me immediately on startup after updating to 1.16.9 as well. I have never had any problem with images before, either.

[Bilb]

Sorry @vidasok801 @slrslr
Your issue is different and is related to some testing code that made it to 1.16.9.
I'll make a 1.16.10 asap to fix your issue.

About your issue @eugenesan
Can you reach out to me on Session (see my gh profile for my sessionID). I might need you to send me a crash dump.

[eugenesan]

Now with 1.16.9 it won't even start with pop-up claim no SSE4.2 support (like in #1602 (comment)) while the log shows SSE 4.2 flag found: true and the CPU clearly supports it.

[eugenesan]

I was able to start 1.16.9 with SESSION_SSE42_OVERRIDE=1 but it crashes a few seconds after the start.
Same as before but now I have a crash dump ;-)

P.S.
#1605 seems like a duplicate

[eugenesan]

About your issue @eugenesan
Can you reach out to me on Session (see my gh profile for my sessionID). I might need you to send me a crash dump.

Thanks for the offer but:

1. I am not comfortable with sharing crash dumps
2. I have no way of running Session on a computer.

I tired parsing the dump using minidump-stackwalk but without symbols I could not make much sense of it.
Here is a snippet that might give some idea (seems like sharp is crashing):

Operating system: Linux
                  6.17.0 -4-generic #4-Ubuntu SMP PREEMPT_DYNAMIC Mon Sep  8 16:09:17 UTC 2025 x86_64
CPU: amd64
     family 6 model 78 stepping 3
     4 CPUs

Crash reason:  SIGSEGV / SEGV_MAPERR
Crash address: 0x0000000000000000
Process uptime: 12 seconds

Thread 18 session-desktop (crashed) - tid: 52487
 0  0x0
     rax = 0x000072b38bfea200    rdx = 0x0000000000000000
     rcx = 0x000072b4eb80fc00    rbx = 0x00003d2c05e62900
     rsi = 0x0000000000000000    rdi = 0x00003d2c05e62910
     rbp = 0x000072b38bfea250    rsp = 0x000072b38bfea1b8
      r8 = 0x000072b38bfea200     r9 = 0x0000000000000001
     r10 = 0x0000000000000000    r11 = 0x000072b320ddc270
     r12 = 0x00003d2c05e62908    r13 = 0x0000000000000001
     r14 = 0x000072b3f751441c    r15 = 0x00003d2c05e62910
     rip = 0x0000000000000000
    Found by: given as instruction pointer in context
 1  sharp-linux-x64.node + 0x1835c
     rbp = 0x000072b38bfea260    rsp = 0x000072b38bfea260
     rip = 0x000072b3f74da35d
    Found by: previous frame's frame pointer
 2  sharp-linux-x64.node + 0x2000b
     rbp = 0x000072b38bfea350    rsp = 0x000072b38bfea270
     rip = 0x000072b3f74e200c
    Found by: previous frame's frame pointer
 3  sharp-linux-x64.node + 0x16eab
     rbp = 0x000072b38bfea390    rsp = 0x000072b38bfea360
     rip = 0x000072b3f74d8eac
    Found by: previous frame's frame pointer
 4  session-desktop-bin + 0xa5355b7
     rbp = 0x000072b38bfea3a0    rsp = 0x000072b38bfea3a0
     rip = 0x00005783b17435b8
    Found by: previous frame's frame pointer
 5  session-desktop-bin + 0x2403b4a
     rbp = 0x000072b38bfea3e0    rsp = 0x000072b38bfea3b0
     rip = 0x00005783a9611b4b
    Found by: previous frame's frame pointer
 6  libc.so.6 + 0xa3da3
     rbp = 0x000072b38bfea4b0    rsp = 0x000072b38bfea3f0
     rip = 0x000072b4e9ca3da4
    Found by: previous frame's frame pointer
 7  libc.so.6 + 0xa3abf
     rbp = 0x000072b38bfea4b0    rsp = 0x000072b38bfea4a8
     rip = 0x000072b4e9ca3ac0
    Found by: stack scanning
 8  libc.so.6 + 0x13747b
     rsp = 0x000072b38bfea4c0    rip = 0x000072b4e9d3747c
    Found by: stack scanning

[eugenesan]

More information (hopefully useful).

I ran session from Ubuntu 24.04 container (distrobox) once and now it works on 24.04, 25.04 and 25.10.

The difference, from the "crashing" runs, was the following msg in the log saveMessages count: 1.

Seems like session was crashing when trying to process one specific msg and after it was processed on an older software stack it no longer crashes.

P.S.
Now I recall having Android client failing to download or show the same msg after which desktop started to crash.
The msg was an attached picture.

[autogris]

With the brand new 1.16.10 still got the blank screen but with no segmentation fault (as it was the case with .6, .7 and .8). AppImage linux x64.

[eugenesan]

And, it broke again after attempting to download a different picture attachment.
As before, I was able to recover by running it once from Ubuntu 24.04 container.

[Bilb]

Hey @eugenesan @autogris
Could you start Session from the terminal, with those environment variables and send me all the *.log files from your Session config folder? ls ~/.config/Session/logs/*.log.
There should be at least a main.log file which give us more context of what is going on, once those 2 env variables are added:
SESSION_DEV=1 DEBUG_IMAGE_PROCESSOR_WORKER=1 <path to the appImage>

Just to be sure, it crashes with every single messages having attachments, or only some?
If that's an issue that your android client had too, it has to be something else than sharp.

[eugenesan]

Hey @eugenesan @autogris Could you start Session from the terminal, with those environment variables and send me all the *.log files from your Session config folder? ls ~/.config/Session/logs/*.log. There should be at least a main.log file which give us more context of what is going on, once those 2 env variables are added: SESSION_DEV=1 DEBUG_IMAGE_PROCESSOR_WORKER=1 <path to the appImage>

I just recreated the issue by sending a photo using "Note To Self" from Android and the desktop "blanked out" immediately.

Before the crash the log didn't anything special and the app showed previously processed (on older Ubuntu system) attachments. Those are the last few line of the log before the crash:

{"level":30,"time":"2025-09-22T03:51:26.442Z","msg":"removeKnownAttachments: About to iterate through 115 messages"}
{"level":30,"time":"2025-09-22T03:51:26.444Z","msg":"removeKnownAttachments: Done processing 115 messages"}
{"level":30,"time":"2025-09-22T03:51:26.444Z","msg":"removeKnownAttachments: About to iterate through 6 conversations"}
{"level":30,"time":"2025-09-22T03:51:26.445Z","msg":"removeKnownAttachments: Done processing 6 conversations"}
{"level":30,"time":"2025-09-22T03:51:26.445Z","msg":"deleteAll: deleted 0 files"}

This is what happened when I sent the new attachment:

getMessagesByConversation around took 1ms
getMessagesByConversation around took 1ms
getMessagesByConversation around took 1ms
getMessagesByConversation around took 2ms
{"level":30,"time":"2025-09-22T03:52:27.912Z","msg":"[updater] isReadyForUpdates false"}
{"level":30,"time":"2025-09-22T03:52:27.919Z","msg":"[updater] auto-update: starting checks..."}
getMessagesByConversation around took 2ms
getMessagesByConversation around took 1ms
{"level":50,"time":"2025-09-22T03:53:16.568Z","msg":"Error sending from webFrameMain:  {}"}
...
{"level":50,"time":"2025-09-22T03:54:26.617Z","msg":"Error sending from webFrameMain:  {}"}
{"level":30,"time":"2025-09-22T03:54:27.923Z","msg":"[updater] checkForUpdates canAutoUpdate true"}
{"level":30,"time":"2025-09-22T03:54:27.924Z","msg":"[updater] checkForUpdates isUpdating false"}
{"level":30,"time":"2025-09-22T03:54:27.924Z","msg":"[updater] checkForUpdates updateVersionFromFsFromRenderer 1.16.10 releaseChannelFromFsFromRenderer stable allowPrerelease false allowDownload false"}
{"level":30,"time":"2025-09-22T03:54:27.925Z","msg":"[updater] checkForUpdates isMoreRecent false"}
{"level":30,"time":"2025-09-22T03:54:27.925Z","msg":"[updater] File server has no update so we are not looking for an update from github current:1.16.10 fromFileServer:1.16.10"}
{"level":50,"time":"2025-09-22T03:54:31.620Z","msg":"Error sending from webFrameMain:  {}"}
...
{"level":50,"time":"2025-09-22T03:55:22.348Z","msg":"Error sending from webFrameMain:  {}"}

• Updater msgs are unrelated since they are random and appeared after the "blanking".

Just to be sure, it crashes with every single messages having attachments, or only some? If that's an issue that your android client had too, it has to be something else than sharp.
Android did not crash now or in the past. But incoming msgs that caused crashes on desktop also failed to load on Android but without crashes. Maybe Android issues are unrelated and causes by network issues plaguing the network for weeks.
Seems like all attachments are causing the issue on newer Linux systems.
Maybe build linux build processes should be refreshed to use newer libs?
Also buildsystem is still using obsolete appimage-tools, but that shouldn't affect runtime/stability.

[eugenesan]

It's not Session specific issue but for some reason main electron binary in many .AppImages (including Session) rely on WAY too many system libraries:

$ ldd session-desktop-bin

linux-vdso.so.1 (0x0000720a06ca0000)
libffmpeg.so => /tmp/session/./libffmpeg.so (0x00007209fb7eb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007209fb7d7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007209fb7d2000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007209fb663000)
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007209fb5f5000)
libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007209fb407000)
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007209fb28b000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007209fb252000)
libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x00007209fb222000)
libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007209fb1e2000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007209fb18c000)
libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007209fb160000)
libatk-bridge-2.0.so.0 => /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007209fb121000)
libcups.so.2 => /lib/x86_64-linux-gnu/libcups.so.2 (0x00007209fb071000)
libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007209fa800000)
libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007209fa784000)
libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 (0x00007209fa602000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007209fa4aa000)
libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007209fb06a000)
libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007209fb065000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007209fa496000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007209fb05d000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007209fa489000)
libgbm.so.1 => /lib/x86_64-linux-gnu/libgbm.so.1 (0x00007209fa482000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007209fa453000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007209fa428000)
libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007209fa3d9000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007209fa38b000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007209fa258000)
libatspi.so.0 => /lib/x86_64-linux-gnu/libatspi.so.0 (0x00007209fa215000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007209fa11e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007209fa0f1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007209f9e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000720a06ca3000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007209fa0e6000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007209fa025000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007209f9df3000)
libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007209f9dec000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007209f9dce000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007209f9d77000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007209f9d44000)
libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x00007209f9d3d000)
libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x00007209f9d38000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007209f9bf9000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007209f9b9a000)
libavahi-common.so.3 => /lib/x86_64-linux-gnu/libavahi-common.so.3 (0x00007209f9b8b000)
libavahi-client.so.3 => /lib/x86_64-linux-gnu/libavahi-client.so.3 (0x00007209f9b77000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007209f9800000)
libgdk-3.so.0 => /lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007209f9a5b000)
libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007209f9a4a000)
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007209f96c3000)
libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007209f96a3000)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007209f9644000)
libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 (0x00007209f9625000)
libcairo-gobject.so.2 => /lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007209f9a3e000)
libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007209f95f3000)
libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0 (0x00007209f94ce000)
libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007209f94bb000)
libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 (0x00007209f94b0000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007209f9469000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007209f939a000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007209f938e000)
libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007209f937f000)
libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007209f937a000)
libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007209f9263000)
libdrm.so.2 => /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007209f924a000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007209f9244000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007209f923c000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007209f922e000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007209f91ea000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007209f90fc000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007209f90c9000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007209f90c2000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007209f90b4000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007209f8efc000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007209f8eda000)
libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 (0x00007209f8ceb000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007209f8cd0000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007209f8c84000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007209f8c24000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007209f8b9e000)
libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007209f8b89000)
libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007209f8b7e000)
libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007209f8b79000)
libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007209f8b6b000)
libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007209f8b66000)
libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007209f8b3e000)
libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007209f8aa3000)
libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007209f8a9a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007209f8a86000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007209f8a77000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007209f8a6e000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007209f8a5b000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007209f8a38000)

No wonder is fails when used on new Linux systems...at least a few of those change ABI between releases.

I thought the purpose of AppImage was to minimize reliance on the host system.

For a contrast, this how included FFMpeg lib looks like :

$ ldd libffmpeg.so

linux-vdso.so.1 (0x00007620ec670000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007620ec2e5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007620ec1ee000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007620ec1c1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007620ebe00000)
/lib64/ld-linux-x86-64.so.2 (0x00007620ec673000)

This how all binaries in AppImage should look like.

P.S.
Ubuntu 25.04 still works.
Looks like Ubuntu 25.10 and probably Debian 13, Fedora 43 and other recent distributions updated one too many library for Session to continue working without updating the build system...

[Bilb]

I see, maybe we will have to make another build once Ubuntu 25.10 is out of beta to have electron support it correctly.
If we build it on ubuntu 25.10, it ought to be supported correctly, but currently github runners do not have support for ubuntu 25.10

[ScuttleSE]

Broken on Arch too. Both appimage and deb. After starting, the screen blanks after 5-10 seconds and this message is repeated ad nauseum:

{"level":50,"time":"2025-09-23T10:50:01.060Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:06.059Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:11.060Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:16.060Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:21.060Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:26.060Z","msg":"Error sending from webFrameMain:  {}"}
{"level":50,"time":"2025-09-23T10:50:31.061Z","msg":"Error sending from webFrameMain:  {}"}

[autogris]

@Bilb Do you have a gpg key so I can share the log with you here? Not comfortable sharing it in plaintext.