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

michaelcsikos commented 4 years ago

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.

EvanHahn-Signal commented 3 years ago

Alas! Thanks anyway for trying it.

miltiad commented 3 years ago

Tried also and sadly it did not solve it. I believe Slack is also using Electron right ? Because my Slack client has no issue I use it everyday for work. Thanks, let me know if I can try something else, I'll be happy to.

miltiad commented 3 years ago

Tested something... I created a local (non-microsoft) account on the same machine, installed Signal (non-beta), linked my account and it works just fine... all pictures shows up properly.

miltiad commented 3 years ago

Tried to take that %AppData% folder and overwrite my original folder (the one with a Microsoft account) but it did not fix the issue

Malivil commented 3 years ago

I use a Microsoft account as well and do not have this issue so I wouldn't assume it's related to the account type.

The only difference I see is that mine doesn't label my account as "Password protected" as it does here: https://github.com/signalapp/Signal-Desktop/issues/4043#issuecomment-707335329 though my account does have a password.

stephenbcollins commented 3 years ago

I have the same issue as that described by the other users - the camera/phone/search and menu icons are invisible on the Signal Desktop UI. I, too, am using Win 10 with multiple (two) monitors. Graphics card is NVIDIA GeForce GT 710. When I use the machine remotely using Windows Remote Desktop (and thus not the native video card) the icons display properly.

michaelcsikos commented 3 years ago

@stephenbcollins True, Signal on the same version of Windows in a virtual machine works, which uses VMware's virtual display driver. I'm now considering running a VM just for Signal.

stephenbcollins commented 3 years ago

So is there a known problem when running on a machine with multiple monitors with any video card, or just with multiple monitors and an NVIDIA GeForce card?

Thanks,

Steve

From: michaelcsikos @. Sent: Tuesday, May 25, 2021 4:54 PM To: signalapp/Signal-Desktop @.> Cc: stephenbcollins @.>; Mention @.> Subject: Re: [signalapp/Signal-Desktop] Windows desktop app all button icons invisible (#4043)

@stephenbcollins https://github.com/stephenbcollins True, Signal on the same version of Windows in a virtual machine works, which uses VMware's virtual display driver. I'm now considering running a VM just for Signal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/signalapp/Signal-Desktop/issues/4043#issuecomment-848320971 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AUHCDQZBIMOMS7K2OPF6RJLTPQTB3ANCNFSM4LGFV62Q . https://github.com/notifications/beacon/AUHCDQ56LJIMBELPVGKQGFLTPQTB3A5CNFSM4LGFV622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGKIFTSY.gif

michaelcsikos commented 3 years ago

@stephenbcollins None of the Signal devs have ever reproduced the problem, so they're not sure.

FloGs commented 3 years ago

I've had the same problem for a few weeks now. Since I don't use the desktop application too often and also didn't realize the missing icons at first (I only noticed that the send button is gone), I unfortunately can't narrow down since when exactly it stopped working and what I changed.

I use Windows 10 Education 21H1 (19043.1083) with all available patches. The error occurs in both the stable (v5.8.0) and beta (5.9.0-beta1) versions. I have only one monitor connected to a Nvidia GTX 1070.

For testing purposes I have installed the beta version. The error also occurs with this one. Already after the first start all icons (and the logo) are missing. Also no logo is displayed on the about page.

As already described in this issue, all images that arrive via the protocol (avatar images, images in messages) work. It only affects the icons of the application. Even if I use the mentioned parameters (--disable-gpu, --force-cpu-draw, --disable-software-rasterizer), the icons are not displayed.

Since I'm not really familiar with Electron, I unpacked the app.asar file as a test and put the unpacked app.asar directory in the resources directory instead of the app.asar file (so it stays the same path, but with a folder instead of a packed file).

Then I used the Developer Tools to find the filename of a button (compose button). I opened the corresponding file with Gimp and saved the SVG to a PNG. I saved the PNG in the same directory with the same filename but with the PNG extension. The file permissions of SVG and PNG file are identical. Afterwards I changed the URL of the webkit-mask in the Developer Tools accordingly. Now the icon was shown correctly.

I can thus rule out that it is a problem with missing files or file permissions. I think I can confirm that it seems to be a problem with rendering the SVG files.

If I have the app.asar directory served to me via http-server (because of CORS ), I can open the about page and see the logo in both Chrome (91.0.4472.124) and Edge Chromium (91.0.864.67).

michaelcsikos commented 3 years ago

Nice work @FloGs, maybe that will help the Signal devs with this issue. I've been putting up with this five days a way for 16 months. I can find most of the invisible buttons when I need to, but sometimes I have to grab my phone because it's just too difficult. The lack of tool tips is still one of Signal Desktop's greatest shortcomings.

FloGs commented 3 years ago

Tried a little more today, but still no solution.

I uninstalled all Nvidia drivers and ran Windows with the standard VGA drivers. Still no icons were displayed.

Unfortunately, it also does not work when I connect to my computer from another computer via Remote Desktop. Even then no icons are displayed.

To be able to use the desktop client somehow, I use the following workaround:

Install Inkscape
Unzip app.asar and put the resource directory under the same name, so that the files from the directory are used
Using the following Windows batch command, Inkscape will convert all svg files to png files and save them under the svg filename. Chromium can display these files (it recognizes that they are png files):

for /r %%i in (*.svg) do (  
  move "%%i" "%%i.orig"  
  "c:\Program Files\Inkscape\inkscape.exe" -z "%%i.orig" -e "%%i"  
)

Inkscape is not perfect and some images are not converted properly (among others the Signal logo). But most of the important icons work and are now displayed again in the application.

Until there is a solution to the problem, I will perform steps 2 and 3 after each update of the Signal Desktop application.

scottnonnenberg-signal commented 3 years ago

@michaelcsikos I notice that you never really chimed in about your user directory, permissions on your computer, basically anything that might be different from a default windows installation. Could even be a certain character in your username, if it's not straightforward ASCII. It really would be great to track this down.

What do you see when you open the dev tools and hover over one of these missing images? Are the dev tools able to render the image?

michaelcsikos commented 3 years ago

Hi @scottnonnenberg my Windows user name is Michael. Where has View > Toggle Developer Tools gone? Apart from using Windows LTSB 2016, my installation is standard.

scottnonnenberg-signal commented 3 years ago

In production builds, you'll need --enable-dev-tools when starting it to get to the dev tools these days.

dsanders11 commented 3 years ago

I've tried to reproduce this with no luck, although the first time I looked at the icons in 'Sources' in the DevTools a few of them displayed the same broken image as the screenshots already in this thread. However, the icons were displaying fine in the app, and I haven't seen that again despite trying to trigger it, so that may have just been a coincidental bug in DevTools.

I do have some thoughts on tests to try to help debug the issue, if @michaelcsikos, @thesu1, @miltiad, @FloGs would be kind enough to try some things since they can reproduce. Test 2, checking the network requests, would be the most enlightening I think given everything already described in this issue, if someone wants to just hit that one. There's a lot here to test, but they're laid out building on the previous test, so they may not all need to be done if interesting results show up in earlier tests.

More Information

I think the following extra info would be good to have, just to help fully describe the systems experiencing the issue to see what's in common, but I don't expect this info to be critical to debugging it.

Under 'Properties' for the disk drive that has your user folder
- Is the file system for the drive NTFS?
- Is 'Compress this drive. to save space' enabled?
Do you know if the disk drive is an SSD or HDD?

Tests to Try

Test 1: Do the emojis in the emoji picker in a conversation display correctly? Those are PNGs rather than SVGs, but they're packed in app.asar so they should exercise similar code paths to be loaded and displayed in the renderer. I have a feeling those will display fine, but worth trying for the data point.
Test 2: How do the network requests look in DevTools for the SVGs which aren't displaying? Under the network tab you can filter just requests for images. Moving between conversations should trigger some requests for SVGs, or you can reload the app while DevTools are open and focused by using the CTRL+R shortcut. This should help figure out if this is a rendering problem, or a problem properly reading the files from disk.
- Do the requests look successful and show a non-zero size in bytes in the size column?
- For any given request for an SVG, does the 'Preview' tab render the image correctly, or is it also broken there?
- For any given request for an SVG, does the raw response under the 'Response' tab look reasonable? Does it look like XML? Can it be copy and pasted to an SVG viewer and display correctly there?

If looking into the network requests produces interesting results like zero sized responses or a malformed SVG response, you can stop there, as that's probably the culprit, although test 3 would still be useful. If everything looks normal with the network requests, please continue to the following tests.

Test 3: Let's see if SVGs in the default Electron app display correctly. Download the ZIP file for an Electron release from their GitHub releases page. The latest version of Signal Desktop at the time of this writing is using Electron v13.5.0, so you can download that release here, assuming you're running 64-bit Windows, download the electron-v13.5.0-win32-x64.zip file. It's not critical to use the exact version of Electron since the default app doesn't change much and is simple, but it will help ensure everything is as similar as possible.
- Extract the ZIP file.
- Try running the electron.exe application. It should display a basic screen about Electron with some buttons at the bottom. Do the icons in the buttons display properly? Those are SVGs in an ASAR file as well, so this will help determine if the problem is with Electron itself, or Signal Desktop.
Test 4: If the SVG icons in the above test display correctly, let's try loading the default Electron app using Signal Desktop. This will help determine if there's something specific about the disk/folders where Signal Desktop is installed.
- Back up your current app.asar in the Signal Desktop folder, and replace it with a copy of resources\default_app.asar from the downloaded ZIP in the previous situation, naming it app.asar.
- Start Signal Desktop, which should now only show the basic screen about Electron. Do the icons in the buttons still display correctly?
Test 5: If the icons are still displaying correctly, let's go a step further and swap in one of the SVGs from Signal Desktop.
- Extract the original backed up app.asar from Signal Desktop, into a folder named something that won't conflict, such as temp. Do not name it app or app.asar.
- Extract the app.asar from the Electron download into a folder named app.asar and delete the ASAR file.
- Replace the file app.asar\octicon\gift-24.svg with any of the SVG icons from the Signal Desktop ASAR.
- Start Signal Desktop. Is the last button's icon changed from a gift SVG to the one you copied from Signal Desktop? Or is that button now simply blank?
Test 6: If the above test displayed the copied SVG, then let's swap it the other direction as a final test.
- Rename the folder app.asar from the previous test to a different name, and rename the folder which is the extracted original Signal Desktop ASAR to app.asar.
- Replace one of the icons in app.asar with one of the SVGs from the Electron ASAR. A simple one to test would probably be to replace app.asar\images\signal-logo.svg so you can easily see when starting Signal. I replaced app.asar\images\icons\v2\group-outline-24.svg in my own testing since I had some group conversations so it was easy to see and the Electron SVGs are also 24x24.
- Start Signal Desktop. Does the SVG from Electron display correctly? Or does it also not display at all?

michaelcsikos commented 3 years ago

Hi David. Thanks for your effort so far.

NTFS, compression is not enabled, 1TB Samsung 960 EVO SSD.

Test 1: Yes, emojis and stickers display fine.

Test 2:

Sizes are > 0 bytes
SVG previews don't work (PNGs do)
"This request has no response data available." This shows for PNGs, too.

Test 3: Images in the buttons display. Test 4: Yes, the images look identical. Test 5: Swapped with add-emoji-outline-24.svg

Test 6: I'm having trouble extracting Signal's app.asar

node:internal/fs/utils:344 throw err; ^

Error: ENOENT: no such file or directory, open 'C:\temp\app.asar.unpacked\ts\workers\heicConverter.bundle.js' ←[90m at Object.openSync (node:fs:585:3)←[39m ←[90m at Object.readFileSync (node:fs:453:35)←[39m at Object.module.exports.readFileSync (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\lib\disk.js:110:17) at Object.module.exports.extractAll (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\lib\asar.js:204:28) at Command. (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\bin\asar.js:72:10) at Command.listener [as _actionHandler] (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\node_modules\←[4mcommander←[24m\index.js:413:31) at Command._parseCommand (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\node_modules\←[4mcommander←[24m\index.js:914:14) at Command._dispatchSubcommand (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\node_modules\←[4mcommander←[24m\index.js:865:18) at Command._parseCommand (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\node_modules\←[4mcommander←[24m\index.js:882:12) at Command.parse (C:\Users\Michael\AppData\Roaming\npm\node_modules\←[4masar←[24m\node_modules\←[4mcommander←[24m\index.js:717:10) { errno: ←[33m-4058←[39m, syscall: ←[32m'open'←[39m, code: ←[32m'ENOENT'←[39m, path: ←[32m'C:\temp\app.asar.unpacked\ts\workers\heicConverter.bundle.js'←[39m }

dsanders11 commented 3 years ago

@michaelcsikos, thanks for the quick and thorough response.

Sizes are > 0 bytes

I can confirm the sizes in the image are the same on my end, and the same as the size on disk, so that checks out.

"This request has no response data available." This shows for PNGs, too.

Interesting, that's something that differs from the behavior I see. That message is expected (although poorly worded) for PNGs and other image formats because it's binary data so DevTools can't display anything, it would be garbled like if you open a PNG with Notepad. However, SVGs are text, and the expected behavior is that the "Response" tab should display that text.

If that behavior is consistent, it could suggest that the response is corrupted in some way such that Chrome doesn't think it's text, despite the content type.

Could you try repeating this test, and refreshing again, to confirm that the "Response" tab is consistently not viewable for those SVGs? If that behavior is consistent, it would make me think the SVGs are being corrupted somehow, which would explain why they're not viewable.

If that behavior is consistent, another possible way to try to confirm the integrity of the response would be to right click on one of the SVG requests and choose "Copy" -> "Copy Response". Then you could paste that into this online data URL viewing tool to see if the SVG can be shown.

I'm having trouble extracting Signal's app.asar

Looks like that's because you've copied/moved the ASAR somewhere outside of its original location. The asar tool is looking for an app.asar.unpacked folder as a sibling of app.asar so that it can copy the unpacked files (which don't exist inside the ASAR) to the output folder. So, you could fix that by copying the app.asar.unpacked folder to the same location so it can be used.

michaelcsikos commented 3 years ago

@dsanders11

Thanks, with app.asar.unpacked it extracted. I tried replacing signal-logo.svg with gift-24.svg but it doesn't display.

dsanders11 commented 3 years ago

@michaelcsikos, I edited my previous comment so I probably didn't do it quickly enough for you to see it before reading. Could you try the following:

If that behavior is consistent, another possible way to try to confirm the integrity of the response would be to right click on one of the SVG requests and choose "Copy" -> "Copy Response". Then you could paste that into this online data URL viewing tool to see if the SVG can be shown.

Also, could you try repeating test 4, and checking if you can view the "Preview" and "Response" tabs for the SVG requests? Since they render in the UI I would think those tabs would work. You can open DevTools with CTRL+SHIFT+I since there's no toolbar in that default app.

Thanks for doing all this testing, it's really helping define and narrow down what's going on here. It's certainly a strange bug.

michaelcsikos commented 3 years ago

When I Copy > Copy response this is what is in the Clipboard: data:image/svg-xml;base64,

With Test 4 and DevTools open, I can't get the Network > Img to show anything. I've tried hitting Ctrl + R and I can see it refreshes, but it's not showing anything in the list. The SVGs do appear in the XHR filter. Example response:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
  <path fill-rule="evenodd" d="M3.75 3.75c0 .844.279 1.623.75 2.25H2.75A1.75 1.75 0 001 7.75v2.5c0 .698.409 1.3 1 1.582v8.418c0 .966.784 1.75 1.75 1.75h16.5A1.75 1.75 0 0022 20.25v-8.418c.591-.281 1-.884 1-1.582v-2.5A1.75 1.75 0 0021.25 6H19.5a3.75 3.75 0 00-3-6c-1.456 0-3.436.901-4.5 3.11C10.936.901 8.955 0 7.5 0a3.75 3.75 0 00-3.75 3.75zM11.22 6c-.287-3.493-2.57-4.5-3.72-4.5a2.25 2.25 0 000 4.5h3.72zm9.28 6v8.25a.25.25 0 01-.25.25h-7.5V12h7.75zm-9.25 8.5V12H3.5v8.25c0 .138.112.25.25.25h7.5zm10-10a.25.25 0 00.25-.25v-2.5a.25.25 0 00-.25-.25h-8.5v3h8.5zm-18.5 0h8.5v-3h-8.5a.25.25 0 00-.25.25v2.5c0 .138.112.25.25.25zm16-6.75A2.25 2.25 0 0116.5 6h-3.72c.287-3.493 2.57-4.5 3.72-4.5a2.25 2.25 0 012.25 2.25z"/>
</svg>

I switched back to Signal's app.asar and the SVGs do not appear in the XHR filter.

dsanders11 commented 3 years ago

When I Copy > Copy response this is what is in the Clipboard: data:image/svg-xml;base64,

Hm. So despite there clearly having been bytes transferred in the request, the response is being thrown away for some reason.

I switched back to Signal's app.asar and the SVGs do not appear in the XHR filter.

This is just a result of how the default Electron app is loading the SVGs, it requests them in JavaScript (so as XHR) and then injects the SVG into the HTML for display.

Going to try to see if you can ever get the SVG data or if that's where the root of the issue is. Let's try to request it the same way the default Electron app does. In Signal Desktop in the DevTools console, try the following code (change the username in the path to match yours):

let response = await fetch(`file:///C:/Users/David/AppData/Local/Programs/signal-desktop/resources/app.asar/images/icons/v2/note-24.svg`);
let svg = await response.text();
let policy = window.trustedTypes.createPolicy('electron-default-app', { createHTML: input => input });
let div = document.createElement('div');
div.innerHTML = policy.createHTML(svg);
document.body.prepend(div);

That should print to the console the SVG contents, and also inject them into the window at the top upper left corner. If it works as intended and can properly load the SVG, it will be interesting to know if you can see the SVG once it's injected into the window. You should also be able to check the request under the XHR filter to see if it's similar to the others, or if it will preview the SVG and let you view the "Response" tab.

I think that's the last test I'd have for you, that should narrow down where the bug is enough to start digging in code.

michaelcsikos commented 3 years ago

It prints undefined to the console, and it displayed in the top left:

The XHR response:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
  <title>note-24</title>
  <path d="M18,3.5a.55.55,0,0,1,.55.55V20a.55.55,0,0,1-.55.55H6.05A.55.55,0,0,1,5.5,20V4.05a.55.55,0,0,1,.55-.55H18M18,2H6.05A2.05,2.05,0,0,0,4,4.05V20A2.05,2.05,0,0,0,6.05,22H18A2.05,2.05,0,0,0,20,20V4.05A2.05,2.05,0,0,0,18,2ZM17,6.5H7V8H17Zm0,3H7V11H17Zm0,3H7V14H17Zm-2,3H7V17h8Z"/>
</svg>

dsanders11 commented 3 years ago

It prints undefined to the console

@michaelcsikos, that's my mistake, I was modifying the code at the last second and left out the console.log(svg); statement. Not needed though, the information you've provided shows that the SVG was loaded successfully and can be rendered in the window.

I'm starting to zero in on a possible cause here, although it's still a mystery why it only affects certain users on Windows, consistently across Electron versions. I'm leaning toward the issue being with Electron/Chromium itself, and specifically with the usage of the SVG images with -webkit-mask-image.

Bit of a tangent, but I just now tried the method @FloGs describes of converting the SVGs to PNGs but leaving the filename the same. Interestingly on my system that does not work, and the request for the image ends up looking just like the ones described here, with no preview and no response data. Peculiar that the two systems act differently in this regard. End tangent.

Let's try to reproduce the issue with only the downloaded Electron. If we can do that then I can try to get the Electron team to weigh in since it will be a more concise issue which reproduces consistently on your system.

For these tests we'll use a "Command Prompt" open to the folder where you have the downloaded Electron we were using in test 3 previously.

First test will be to use Electron to simply load a web page that uses -webkit-mask-image to check that your system can in fact properly render that CSS property. You can run the following command to point electron.exe at the URL and it should load it up:

electron.exe https://developer.mozilla.org/en-US/docs/Web/CSS/mask-image#Examples

Here's what it looks like on my Windows 10 system:

MDN Page

Next I've made a small test app for Electron which tries to load the Signal logo in various different ways in conjunction with -webkit-mask-image in the hopes that it might narrow things down to a particular area to look. You can download the repo as a ZIP from this URL: https://github.com/dsanders11/electron-webkit-mask-image-test/archive/refs/heads/main.zip

Extract that to a folder somewhere and use the following command to run it with electron.exe. Note that one of the images is loaded from the GitHub servers, so you'll need Internet connection when you run the test.

electron.exe test-app\

Here's what it looks like on my system, it should display four copies of the logo if they are all loaded successfully:

ElectronWebkitMaskImageTest

scottnonnenberg-signal commented 2 years ago

Let me just weigh in here: I believe that this behavior is a low-level Chromium interaction with certain graphics hardware/drivers. If we could gather up the specific data there and hand Electron/Chromium a minimal repro, that would go a long way towards fixing this.

dsanders11 commented 2 years ago

Let me just weigh in here: I believe that this behavior is a low-level Chromium interaction with certain graphics hardware/drivers.

@scottnonnenberg-signal, I agree it's probably something lower level in Electron/Chromium, but I'm not really seeing how it could be a graphics hardware/drivers issue. From the earlier comments in this issue, there was never any success with trying the usual flags related to GPU/hardware acceleration/software rendering. With the tests @michaelcsikos has generously done, it seems clear his system is capable of rendering the SVGs in the app. The requests make it seem almost like CORB is being triggered, where there was a successful request for the image, but the response data was thrown away by Electron/Chromium for unclear reasons.

If the requests for the SVGs in DevTools showed the response data I'd be more inclined to think it's a rendering issue, but from what I've seen it feels more like the data for the image isn't getting to where it needs to be.

scottnonnenberg-signal commented 2 years ago

@dsanders11 Capable of rendering SVGs sure, but via --webkit-mask-image?

dsanders11 commented 2 years ago

@dsanders11 Capable of rendering SVGs sure, but via --webkit-mask-image?

Again, I'd be right there with you if the requests looked normal and successful, with a viewable response data. Then I'd say yes it looks like it has the data and just fails to render it. But from what I've seen, I can't be positive it actually has the SVG data, the requests are abnormal, so that can't be discounted. I don't see how a graphics hardware/driver issue would bubble up to make a request abnormal in that manner where DevTools can't/won't show the response payload.

My previous comment with more tests should provide more insight since it tests -webkit-mask-image in various different ways. I didn't think of it in that comment, but another good test to try would be changing the value to be a data URL with the SVG base64-encoded since that entirely removes the request from the process and just tests -webkit-mask-image.

michaelcsikos commented 2 years ago

@dsanders11 The electron.exe https://developer.mozilla.org/en-US/docs/Web/CSS/mask-image#Examples test looked the same for me.

dsanders11 commented 2 years ago

@michaelcsikos, this has been very helpful, thank you! Could you try that last test again, but including the --disable-web-security flag? I have a suspicion something with web security is getting confused and blocking the requests for SVGs, so that might disable it and allow them. So the command would be:

electron.exe --disable-web-security test-app\

@scottnonnenberg-signal, there we go, looks like @michaelcsikos has a system which can render -webkit-mask-image correctly. Electron was able to display the MDN article on mask-image with the demo image correctly, and the test project I made for testing is only showing the last logo of the four. They all use -webkit-mask-image, they just use different url("...") values for the property.

In order of the logos:

References it the same way Signal does, as a relative path, so it uses file:// protocol
References it with a custom test:// protocol registered in main.js and serves files from disk
References it with the http:// protocol which is intercepted in main.js and serves files from disk
References it with the https:// and the URL is the logo SVG in this GitHub repository, so it's the only one that actually loads over the network

So it's clear that the bug isn't a rendering bug with -webkit-mask-image, but a bug with loading the SVG itself. The requests triggered by the CSS url("...") value is failing when that request is file:// or handled by a registered/intercepted protocol in Electron.

Of course, the next question is why. :smile: The behavior feels like what would happen if CORB was triggered and Electron/Chromium blocked reading the request body. It will be interesting to see if disabling web security fixes it. Then it will be a matter of determining why some specific systems trigger that behavior.

michaelcsikos commented 2 years ago

@dsanders11

dsanders11 commented 2 years ago

@michaelcsikos, thanks! Was worth a shot, and is another data point. I think there's enough data here to poke the Electron team and see if anyone can make heads or tails of what's going on with your system.

dsanders11 commented 2 years ago

@michaelcsikos, I have another test to try if you're still willing. Wish I could reproduce this locally so I didn't have to bother you so much. Unfortunately debugging something like this is iterative and exhaustive, and Chromium is a very large codebase to look through so the more it can be narrowed down the better. The good news is now it can be tested entirely with Electron and you don't need to mess with your Signal install.

Here's another variation on the four logo test: https://github.com/dsanders11/electron-webkit-mask-image-test/archive/refs/heads/more-tests.zip

Note that I tweaked the shade of blue for the logo to match the actual logo color so that they all look the same with these most recent changes, so don't worry about any color change, that's expected.

It now launches two windows, they may be stacked totally on top of each other so you may need to move one to see the other, they have different titles to help tell them apart. When everything is working they're identical and show the four logos.

I've left the first and fourth logo variants the same, but I've changed the second one to be referenced from an <image> element so that CSS isn't involved, and the third one is referenced in CSS as background-image instead of -webkit-mask-image. That should provide insight into if it is a bug specifically involving CSS, which will help narrow down the code paths.

michaelcsikos commented 2 years ago

dsanders11 commented 2 years ago

Fantastic, thanks.

dsanders11 commented 2 years ago

@michaelcsikos, out of curiosity, do you have the Chrome/Chromium browser on that system? Could you try opening index.html from that most recent test with Chrome/Chromium and see if the logos display? On my system, three out of the four logos display, only the first one doesn't. It may provide a clue if whatever issue that's affecting Electron is also effecting general Chrome/Chromium on your system, when loading the SVG files from disk.

michaelcsikos commented 2 years ago

@dsanders11 I just tested with Chromium Version 98.0.4706.0 (Developer Build) (64-bit). It's the same as the test:

In Firefox 94.0.1, icons 2, 3 and 4 display.

dsanders11 commented 2 years ago

@michaelcsikos, great, thanks for running that and also for trying it in Firefox as well. That provides a lot of data with that test, whatever the issue is in Chromium rather than Electron. Unfortunately that means there's a really big code base to try to find the needle in the haystack, but maybe we can get a Chromium developer to take an interest in your issue. I'll see if I can make some time in the next few weeks to investigate the code base and see if I can find anything interesting.

michaelcsikos commented 2 years ago

@dsanders11 OK, thanks. At least we have a PC which is reliably reproducing the issue.

dsanders11 commented 2 years ago

@michaelcsikos, definitely, your willingness to help test things is very helpful here.

indutny-signal commented 2 years ago

Fantastic work @dsanders11 ! Did you file a chromium issue yet, by any chance?

dsanders11 commented 2 years ago

@indutny-signal, thanks! A lot of the credit goes to @michaelcsikos, he's been thorough and provided screenshots when relevant, which has made debugging this a lot easier despite the obscure nature of the bug.

I haven't filed a Chromium issue just yet, I was going to let it sit for a few days in case new ideas come to me (which a few have, see below :smile:) and maybe ping some of the other users in this issue who said they were having the same problem. There's always a small chance that there are multiple causes for the different users not seeing icons, so would be good to have another person who is having the issue confirm that latest test in Chromium only, which would add more data points.

@michaelcsikos, it occurred to me that your original comment on this issue mentions that you first encountered the bug when you upgraded to Signal Desktop v1.32.1, and that rolling back to v1.29.6 successfully brought back the icons. It looks like v1.29.6 was using Electron 6.1.4, and v1.32.1 was using Electron 8.0.3.

Could you try downloading Electron 6.1.4 and run the test from this comment again? If going back to Electron 6.1.4 makes all the logos show up, then we can pinpoint between which two versions of Electron the bug was introduced, which would tell use between which versions of Chromium the bug started, which will greatly reduce where we need to look for the bug. So if Electron 6.1.4 shows all logos, you could then try later versions of Electron, starting with 7.0.0, to see which is the earliest version in which some of the logos don't display.

michaelcsikos commented 2 years ago

Electron 6.1.4:

Electron 7.0.0:

dsanders11 commented 2 years ago

@michaelcsikos, thanks!

So for those following along, that narrows the range of Chromium releases where the issue was first introduced to between v76.0.3809.146 and v78.0.3905.1.

I'm going to look into the feasibility of getting older releases of Chromium on Windows for testing so that the range could be narrowed down further, but with those releases being 2 years old, this may be as narrow as we can get the range.

michaelcsikos commented 2 years ago

@dsanders11 It also works fine in 6.1.12. If there are any versions prior to 7.0.0 that I can test, let me know.

dsanders11 commented 2 years ago

@michaelcsikos, I asked the Electron folks if there was a way to get old Chromium builds to test this, and they pointed me to a tool Chromium has for exactly this purpose: bisect-builds.py. This script will narrow it down to the exact tagged version of Chromium where the issue first appeared, which is as narrow as it can get, and shouldn't include more than a few hundred commits. This will greatly increase the odds of finding the root cause.

I'm away from my home Windows PC at the moment, but I gave a quick test of the process with a Windows VM I have. The link above has more detailed instructions, but I'm going to provide a quick overview here of how I got it working for this particular situation with a local file. If anything seems to go wrong with these instructions, you can always check the more detailed instructions linked above.

You'll need Python 2 or Python 3 installed on your system to use the script. If you don't have Python already, I'd recommend just grabbing the latest Python 3 through the Windows Store as that will be the quickest and easiest way to get it.

You can save bisect-builds.py from the GitHub mirror of the Chromium source tree: https://raw.githubusercontent.com/chromium/chromium/master/tools/bisect-builds.py. I right-clicked and used "Save As...", just ensure that the file extension is .py rather than .py.txt. Save the script into the folder with the test you've been running, so it should be a sibling of index.html.

Run the following command in "Command Prompt" to start the script, adjusting the full path to index.html to be accurate for your system. In my testing it needed the full path.

python bisect-builds.py -a win64 -g 76.0.3809.146 -b 78.0.3905.1 --use-local-cache --verify-range -- --no-first-run file://C:\Users\David\Downloads\test-app\index.html

From there it's simply a matter of waiting for the window to open, seeing if the last 3 logos all display (I don't think the first logo will ever display, but if it does that's fine and is still a success if the other 3 logos also display), closing the window, and entering "g" or "b" in the "Command Prompt" for good or bad results, respectively. NOTE: Sometimes I accidentally tripped "QuickEdit Mode" in the "Command Prompt", which is where there's a solid white block visible, which pauses execution. If that happens to you as well, hitting enter should resume execution.

It will likely need to run through 10-20 versions, but once that's done it should spit out a URL for the final range of Chromium versions where the issue appeared.

Hopefully those instructions were fairly clear, I'm half asleep at the moment, so just let me know if anything needs clarification or you run into any problems.

michaelcsikos commented 2 years ago

@dsanders11 Unfortunately, the very first test is not showing the last 3 images; only the last one is displayed. I've moved the range right back to -g 50.0.2657.10 and it still doesn't display properly.

dsanders11 commented 2 years ago

@michaelcsikos, well that was unexpected! This issue never ceases to perplex, you're running into quite the bug here it seems. Thanks for taking the initiative to bump the good range further back, that was a good idea.

Assuming that the script did indeed pull the correct older versions (which on face value I have to assume it did, but I'll think on that a little just so we don't get misled if something went wrong), then that almost suggests that it's always been broken on Chromium on your system, but for whatever reason Electron 6 fixed it. 🤔

Just shooting from the hip here, but now that we have this data point, maybe let's try going the other way, and seeing how things look in Electron 5, and maybe Electron 4? Once we saw that it looked correct in Electron 6 I had assumed it was the usual situation with bugs where something works up until a new version breaks it, but it looks like we can't make that assumption in this case.

michaelcsikos commented 2 years ago

@dsanders11 I just tried Electron 5.0.5 and 4.0.4 and all the images display. Does this mean it's a change in Electron, not Chromium which caused the behaviour to change? Can Git show all the changes from 6.1.12 to 7.0.0?

dsanders11 commented 2 years ago

@michaelcsikos, not sure, I’ll have to contemplate this a bit more. It’s perplexing that it’s broken in all versions of Chromium you’ve tried, but not in older versions of Electron. That’s an unusual situation: that it doesn’t work in Chromium (but does in Firefox) due to some unknown issue, and Electron somehow fixed that issue (most likely inadvertently), and then whatever fixed that issue went away after Electron 6. :thinking:

My initial reaction was it makes me suspect of the results of the bisect-builds.py, but the output you screenshotted all looks good and reasonable, so it would be pretty unlikely anything is wrong there. Just has me thrown off so now I’ll have to reevaluate the big picture of symptoms and hints here.

Thanks for trying Electron 5 and 4. If you’re willing, maybe keep going further back, let’s find out if it was ever broken in Electron, then fixed, then broken again, or if it always worked from the start of Electron, and then stopped working between 6 and 7. That's the best next step I can think of at this moment.

The further back in Electron versions you go, there will be issues running that test as we did originally, since the Electron APIs have changed over time. However, with what we’ve determined since I made that test, all you need to reproduce is the index.html, so with older versions of Electron you can simply run it as electron.exe index.html, and a single window will open. Maybe double check on Electron 4 with that method of running the test just to confirm nothing accidentally changes (it should act the same), and then run older versions of Electron like 3, 2, 1, etc.

I'm going to be a bit busy as far as free time goes the next few days, so feel free to take your time trying that out, I probably won't be able to review your findings for a little bit.

signalapp / Signal-Desktop

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

More Information

Tests to Try