Windows: All button icons are invisible when installed alongside Photoshop 6.0

[michaelcsikos]

All buttons and icons are invisible in both light and dark themes in version 1.32.1. I have uninstalled and reinstalled, no change. This is in all conversations and even the close button in Preferences. There are no tool tips so it's impossible to use. There should be tool tips. I have rolled back to 1.29.6.

Now Signal nags me like crazy to install the new one a hundred times per day. How do I disable the automatic updates? It looks like you've disabled the hosts hack.

[scottnonnenberg-signal]

What exactly do you mean by 'buttons and icons are invisible?' Can you provide some screenshots, or describe what you mean more completely?

[michaelcsikos]

The search and menu button images at the top right are invisible, the context buttons for each message are invisible. Literally every image for every button in the whole application is invisible.

Images are visible in Version 1.29.6:

Not visible in Version 1.32.1:

[scottnonnenberg-signal]

It seems like something perhaps went wrong during setup. What happens if you re-install from https://signal.org/download? Your data will be safe as long as you don't uninstall - a reinstall on top of will not remove data.

[michaelcsikos]

I have reinstalled at least five times.

[scottnonnenberg-signal]

You might try starting Signal.exe from the command line with --disable-gpu or --disable-software-rasterizer - this may tell us that it's some sort of graphics problem on your computer.

What specific version of Windows are you running?

[michaelcsikos]

OK, I tried each arg with 1.32.1, no difference. This PC is running Windows 10 Enterprise LTSB 1607.

The GPUs are:

• GeForce GTX 1060
• Intel HD Graphics 630
• AsusTek MB169B+ (a USB monitor)
• Trigger 6 External Graphics (a USB adaptor with 2 ports)

I have tried closing and reopening on each screen with each arg.

The cmd prompt shows the following:

Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR C:\Users\Michael\AppData\Local\Programs\signal-desktop\resources\app.asar\config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: C:\Users\Michael\AppData\Roaming\Signal
config/get: Successfully read user config file
x-attr dependncy did not load successfully
config/get: Successfully read ephemeral config file
(node:14332) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\Michael\AppData\Local\Temp\b5d1dd1e-70ad-4e42-bc4f-cbb09222d076.tmp.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:14332) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\Michael\AppData\Local\Temp\b5d1dd1e-70ad-4e42-bc4f-cbb09222d076.tmp.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:14332) DeprecationWarning: Passing functions, DOM objects and other non-cloneable JavaScript objects to IPC methods is deprecated and will throw an exception beginning with Electron 9.
(node:14332) DeprecationWarning: Passing functions, DOM objects and other non-cloneable JavaScript objects to IPC methods is deprecated and will throw an exception beginning with Electron 9.

[michaelcsikos]

I installed 1.32.0, and that's where the problem started. So, someone needs to do a Git diff between 1.29.6 and 1.32.0 and work out what broke it. In the meantime, I will stick with 1.29.6 and put up with the constant nagging to install the broken update.

[scottnonnenberg-signal]

The change that likely caused this is the move from Electron 6 to Electron 8, which brings with it many security improvements and fixes. No git diff necessary.

Given that you are the only one who has reported this issue, we're looking for any information you can provide on why your computer might be so unique.

When you open the dev tools (View -> Toggle Developer Tools) are you able to find where the images should be and inspect those elements? Does it look like those files are present on your system, or are then entirely missing? Essentially: is this a rendering problem or a file existence problem?

[michaelcsikos]

The images are all in the application package resources\app.asar, e.g. ../images/icons/v2/add-emoji-outline-24.svg. I extracted the asar and those files do exist in the package. I copied the files into app.asar.unpacked but they still don't display.

[thesu1]

I have the same issue and am running v 1.3.3.1 on Win 8.1. It's my first install.

No emoji, sticker, recording, or attachment icons. If I hover over the correct area, I can access the functionality though. Also, no "Note to Self" icon.

No "x" to close settings:

No "x" to close keyboard shortcuts:

Here's what I see when I inspect element:

When I click on the image link, the file can't be found.

Images nowhere in the app.asar or app.asar.unpacked folders.

[michaelcsikos]

I'm glad I'm not the only one experiencing this problem. The icons are inside the app.asar file, which is like a compressed folder, that's why Firefox can't see it. There's an asar format plugin for 7-Zip which allows you to extract it. (See here.) The icons do exist in the asar, so I'm quite sure that's not the problem.

If there were tool tips on the invisible buttons it would be so much easier to put up with. Why are there no tool tips?

[kenpowers-signal]

@thesu1 Can you try right-clicking on that URL in the element inspector and then click "Reveal in Sources Panel" on the context menu that comes up?

[thesu1]

@kenpowers-signal I only had "Copy link address" as an option. Not sure what I'm looking for, but I did browse to it in the Sources tab.

All the other images look broken.

[scottnonnenberg-signal]

@michaelcsikos @thesu1 When we install Signal Desktop on windows, and when many other people install Signal Desktop on windows, they don't see this. So we're looking for the unique thing about your setup.

Is it something about your display hardware? Or perhaps you're doing something interesting on your filesystem so your AppData directory somehow inaccessible? Anything additional information you can provide would be useful.

[thesu1]

@scottnonnenberg-signal I can't think of customizations I've done, but here's my setup.

GPU: Intel HD Graphics 4600
Monitor: Dell XPS 2720

Profile photos, including my own, are visible. Perhaps the way the file is referenced makes a difference?

[michaelcsikos]

Reveal in Sources panel doesn't show up for me, either. My laptop has 6 extra monitors and is running Windows 10 Enterprise 2016 LTSB. Apart from that it should be pretty standard: i7-7700HQ CPU, 32 GB RAM, 64-bit. I listed the GPUs earlier. I don't think there's anything unusual about my %AppData%. The updates work fine which is via the Local app data folder. The message cache works, profile pictures, GIFs, photos and videos display, Preferences, and everything seems fine for me except for the -webkit-mask SVGs.

[scottnonnenberg-signal]

@michaelcsikos @thesu1 One big difference between the broken icons and the attachments which are showing up properly is the location on disk. So let's do a test - what do you see when you start the app? On the loading screen, on the 'Welcome to Signal' screen - do you see the Signal logo?

If that works, it's from the same location as the broken icons.

So that suggests that it's a hardware rendering problem. What happens if you go to Command Prompt and start Signal with these arguments? Signal.exe --disable-gpu --force-cpu-draw?

[michaelcsikos]

I don't see the logo while starting up, even with --disable-gpu --force-cpu-draw. The 3 dots animation displays, though.

[scottnonnenberg-signal]

@michaelcsikos When you start up, it should look like this:

So we've established that on your windows machine, in particular, we can't extract built-in images from the .asar file. But we can display attachments you receive or send. So it's not graphics; it's some sort of filesystem thing. Hm...

[michaelcsikos]

Do the files get extracted on demand to the app.asar.unpacked folder?

[scottnonnenberg-signal]

No; there's a system inside of Electron that redirects disk access to the .asar archive, which is like a .tar file. All of our built-in images are all in that .asar.

[michaelcsikos]

If there was one image that wasn't in the asar that we could test it would help.

[scottnonnenberg-signal]

@michaelcsikos I don't think that's the right avenue. Given that we can install Signal Desktop on stock windows machines, and this problem doesn't happen, the right next step is to look at the way your computer differs from stock windows. Maybe it's just that you're on Enterprise 2016 LTSB, and it has some weird bug? We don't test on that build of Windows - we test on the Windows 10 build available to everyone.

[michaelcsikos]

@thesu1 is using Windows 8.1 Pro. I tested it on a Win 10 Enterprise 2016 LTSB virtual machine (VMware on my PC) and the images render fine. Is there any other way I can test if files in the asar are accessible?

[scottnonnenberg-signal]

You can manually unpack the .asar file with the npm module asar if you doubt that the files are in there. But keep in mind: if the app runs, files are being pulled out of the .asar just about all of our application code is in there.

[michaelcsikos]

I know the files are there. I renamed the asar and extracted it to a folder named app.asar. Signal runs. I can open the SVG files from this folder, but Signal still doesn't show them.

[thesu1]

@scottnonnenberg-signal verifying I don't see the logo on startup either. Only "Loading..." and the 3 dots.

[miltiad]

Same issue here on 1.34.2 using Windows 10 Home

[TheBlackSheep3]

I've experienced the same issue on 1.36.3 using Windows 10 Enterprise.

[michaelcsikos]

@dsanders11 If there's light at the end of the tunnel, I'm a happy man. I've been using Signal with invisible buttons every workday for over 20 months; another 6 months won't break me.

[hump]

Followed your exciting bug hunt in the last days :)
Found a similar issue in this chrome addon today:
https://jasonsavard.com/de/Checker-Plus-for-Gmail
Issue is in Chrome & Edge, but not in Firefox:

It uses also svg for this 2 buttons:
chrome-extension://oeopbcgkkoapgobdbedcemjljbihmemj/images/google-plus-sign.svg
chrome-extension://oeopbcgkkoapgobdbedcemjljbihmemj/images/noPhoto.svg

[dsanders11]

@hump, thanks for the extra data points!

@michaelcsikos, could you try this index.html (https://github.com/dsanders11/electron-webkit-mask-image-test/archive/refs/heads/minimal-reproduce.zip) in Chromium (any version) to confirm it reproduces the bug? It's the same as we've been working with, just with some stuff removed which is unlikely to be involved in the bug. Trimming the fat so I can get a nice small HTML file to use for opening a Chromium bug. And would you mind if I used that screenshot showing the difference in the "Type" columns in the that bug report? It really illustrates things well and drives home the point that something odd is going on.

[hump]

my edge and chrome show this on the above test case:

[dsanders11]

@hump, thanks for the info! Think you could open DevTools and see if the network requests look the same as @michaelcsikos, where some of the requests are listing "svg-xml" for type?

[hump]

see this in chrome & edge:

[hump]

<!DOCTYPE html>
<html lang="en">
  <body>
      <img src="signal-logo.svg" />
      <object data="signal-logo.svg" type="image/svg+xml"></object>
  </body>
</html>

img does not work with my chrome/edge (has mime text/xml), only with firefox
object works on my 3 browsers...

[dsanders11]

@hump, great, thanks for testing that out, that adds an interesting data point that on your system, in Edge, the type column is reading "text/xml" for the broken requests.

@hump, @michaelcsikos, could you both try in the other browser, Chrome/Chromium and Edge, and share a screenshot of the network requests? I want to see if that different in type is just because of the different browser, or if your two systems are acting slightly differently, despite hitting the same issue. Thanks!

[hump]

same on chrome here:

[hump]

how can our windows systems differ?
how does windows detect mime types?
i would assume the windows registry...

[dsanders11]

@hump swooped me here while I was writing this up!

@michaelcsikos, @hump, good news for you, it looks like the reason it only happens on your systems is on Windows, Chromium is pulling the association between file extension (.svg in this case) and the MIME type out of the Windows registry. Somehow the Windows registry on your systems has had a change made which is associating .svg with an incorrect MIME type, breaking the requests.

I've purposefully changed mine on a Windows VM and can confirm I can reproduce the exact same issue as you both.

As @hump's screenshot shows, you need to check the association in the Windows registry using "Registry Editor" under the HKEY_CLASSES_ROOT\\.svg\Content Type key. That value should be "image/svg+xml", and changing it to that should make things work as expected on your systems!

[dsanders11]

Shout out to @indutny-signal for helping me figure out the registry association, but @hump figured that part out independently as well!

[dsanders11]

@hump, can you confirm that changing the value there fixes your system?

[hump]

i must admit i am actual no signal user - but after changing the value in my registry, the test case showed correctly now in my chrome & edge and also my gmail addon buttons are visible now :)

[hump]

ok, i am a signal user again and i can use it on windows with nice buttons now :)

[hump]

so we learned as developer: do not trust the windows registry for mime types.
https://www.howtogeek.com/192628/mime-types-explained-why-linux-and-mac-os-x-dont-need-file-extensions/

[michaelcsikos]

Wow! Indeed, my HKEY_CLASSES_ROOT\.svg\Content Type was set to image/svg-xml. Changing it to image/svg+xml fixes everything.

I also worked out which software installer changed the value: Adobe Photoshop 6.0. I tested this in a virtual machine and the installer changes it to image/svg-xml, and also adds a .svgz key with the same Content Type. I purchased Photoshop 6.0 in the year 2000 and have been using it ever since. I now have a .reg file to fix this whenever I install this software.

Thank you @dsanders11 and @hump for all your help in resolving this issue.

Fix-svg-Content-Type.reg

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.svg]
"Content Type"="image/svg+xml"

[HKEY_CLASSES_ROOT\.svgz]
"Content Type"="image/svg+xml"

[dsanders11]

@michaelcsikos, glad this is now fixed for you, I'm impressed you toughed through the invisible icons all those years. Glad I could help resolve that for you.

Thanks for going the extra mile and figuring out the guilty party on mangling that registry value. I tried searching the web a bit for "svg-xml" when I first spotted it, but unfortunately with the hyphen, hard to get good Google results, so, hard to know how many other people that has bit over the years. I can't imagine Adobe did that intentionally, I'm guessing someone fat fingered the - for the + and well it went under the radar.

I'll look into making issues with Chromium and Electron. Chromium may have opinions and choose not to address the issue, but Electron may be able to do something within Electron (like happened in those older versions), since it's a a very not good situation when a desktop app going for native feel gets broken like this in ways which simply don't happen to truly native apps. It's a big trap lurking under there.

[michaelcsikos]

I also tried DuckDuckGo and Google; as you say it's pretty difficult to search.

Photoshop 6.0 included a standalone SVG viewer which also sets the (Default) for .svg and .svgz to Adobe.SVGCtl. The uninstaller for one or the other actually removes both keys from the registry.

In my opinion, Chromium should just automatically sanitise image/svg-xml to be image/svg+xml.

[thesu1]

I also worked out which software installer changed the value: Adobe Photoshop 6.0.

@michaelcsikos Wow, I have Adobe Photoshop 6, too. Who would have thought that was the culprit?

[stephenbcollins]

Me too! From: thesu1 ***@***.*** Sent: Monday, November 29, 2021 2:57 PM To: signalapp/Signal-Desktop Cc: stephenbcollins; Mention Subject: Re: [signalapp/Signal-Desktop] Windows desktop app all button icons invisible (#4043) I also worked out which software installer changed the value: Adobe Photoshop 6.0. @michaelcsikos <https://github.com/michaelcsikos> Wow, I have Adobe Photoshop 6, too. Who would have thought that was the culprit? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4043 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUHCDQ5F6IPLSDQUCXXG53DUOOICTANCNFSM4LGFV62Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . <https://github.com/notifications/beacon/AUHCDQ4KONUQEQ4ZELLU3ILUOOICTA5CNFSM4LGFV622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHKB3SYI.gif>

[dsanders11]

@michaelcsikos, Chromium just merged a change I submitted which adds SVGs to the list of extensions it won't consult the Windows registry on, so that will at least fix SVGs. They didn't seem interested in any larger changes around the functionality. I still have the issue on Electron about changing the behavior in Electron itself, but haven't pursued it further yet.

So that Chromium change should make it's way into Electron in ~4 months and Signal some time after that.

[dsanders11]

This issue should be fixed and be able to be closed now. The upstream fix shipped in Electron v17.

[indutny-signal]

Yay!