White Screen when run under xorg forwarding #4040
Comments
|
What kind of graphics hardware is being used by Electron in that environment? Sounds like it has something to do with that, given that the default background color for our windows is blue. What happens when you start Signal Desktop with |
|
I have the same issue, as @TheBlueMatt, running my signal-client in a docker-environment. Starting with the following options, results in the picture below: Somehow, these lines from the logs, look suspicious to me, without having any deeper knowledge of the code or electron itself. {"name":"log","hostname":"c066199424cb","pid":7549,"level":40,"msg":"(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false". It will change to be "true" in Electron 9. For more information please check https://github.com/electron/electron/issues/18397","time":"2020-03-13T10:52:07.915Z","v":0} {"name":"log","hostname":"c066199424cb","pid":7549,"level":40,"msg":"(electron) 'setAutoHideMenuBar function' is deprecated and will be removed. Please use 'autoHideMenuBar property' instead.","time":"2020-03-13T10:52:12.358Z","v":0} The complete logs from the docker-container: |
|
I'm seeing the same issue. I run the desktop from a mint 18 system. Tried with production and beta, same result. |
|
All: Please provide the details of your graphics hardware and linux kernel. Please also try running with this extra command, see if it makes a difference: |
|
Another thing that would help is trying stable and develop-channel chromium builds. Electron shares most of its underlying technology with chromium. |
|
This is exactly the same issue that was mentioned by @maysara in issue 3281 (the blue screen issue). I tried various Docker setups and I was able to reproduce it with all of them (maybe it's time for an official Docker image?). So I guess you will be able to reproduce it as well, with one of them. ExampleSo you could try this Short path (using someone's image as long there's no official Signal Desktop image)$ docker run -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY -e XAUTHORITY=/tmp/xauth --device /dev/snd -v /dev/shm:/dev/shm -v $XAUTHORITY:/tmp/xauth --hostname 'sigaldebug' --name signal --privileged rdvde/signal -c '--no-sandbox --enable-logging --disable-software-rasterizer --disable-gpu'Log output (click me)Build the image on your own
$ docker run -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY -e XAUTHORITY=/tmp/xauth --device /dev/snd -v /dev/shm:/dev/shm -v $XAUTHORITY:/tmp/xauth -v $XAUTHORITY:/user/.Xauthority --privileged --name signal signal_debug -c '--no-sandbox --enable-logging --disable-software-rasterizer --disable-gpu'Log output (click me)
The same issue happens in Chromium (Click me for a recipe to reproduce this issue).# I just extended the mentioned Dockerfile for Signal, so this is not the smallest file to reproduce this
FROM debian:stable-slim
ENV DEBIAN_FRONTEND noninteractive
RUN echo 'deb http://httpredir.debian.org/debian testing main' >> /etc/apt/sources.list && \
apt-get update && apt-get install -y \
chromium \
chromium-l10n \
fonts-liberation \
fonts-roboto \
hicolor-icon-theme \
libcanberra-gtk-module \
libexif-dev \
libgl1-mesa-dri \
libgl1-mesa-glx \
libpango1.0-0 \
libv4l-0 \
-t testing \
fonts-symbola \
--no-install-recommends \
&& rm -rf /var/lib/apt/lists/* \
&& mkdir -p /etc/chromium.d/ \
&& /bin/echo -e 'export GOOGLE_API_KEY="AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k"\nexport GOOGLE_DEFAULT_CLIENT_ID="811574891467.apps.googleusercontent.com"\nexport GOOGLE_DEFAULT_CLIENT_SECRET="kdloedMFGdGla2P1zacGjAQh"' > /etc/chromium.d/googleapikeys \
&& echo 'deb http://httpredir.debian.org/debian testing main' >> /etc/apt/sources.list \
&& apt-get update \
&& apt-get upgrade -y \
&& apt-get install -y locales ttf-wqy-zenhei chromium chromium-l10n fonts-liberation fonts-roboto \
&& localedef -i zh_TW -c -f UTF-8 -A /usr/share/locale/locale.alias zh_TW.UTF-8 \
&& apt install -y apt-utils curl dbus-x11 libx11-xcb1 gnupg apt-transport-https libasound2 \
&& curl -s https://updates.signal.org/desktop/apt/keys.asc | apt-key add - \
&& echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | tee -a /etc/apt/sources.list.d/signal-xenial.list \
&& apt update \
&& apt install -y signal-desktop \
&& apt-get autoclean -y \
&& groupadd -r user \
&& useradd -r -g user -G audio,video user \
&& mkdir -p /home/user/Downloads \
&& chown -R user:user /home/user \
&& usermod -u 1000 user \
&& groupmod -g 1000 user \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
ENV LC_CTYPE=zh_TW.UTF-8 \
GTK_IM_MODULE=fcitx \
QT_IM_MODULE=fcitx \
XMODIFIERS='@im=fcitx'
USER user
ENTRYPOINT [ "/usr/bin/chromium" ]
CMD [ "--user-data-dir=/home/user --no-sandbox" ]Then run with $ docker build -t chromium_debug .
$ docker run -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY -e XAUTHORITY=/tmp/xauth --device /dev/snd -v /dev/shm:/dev/shm -v $XAUTHORITY:/tmp/xauth -v $XAUTHORITY:/user/.Xauthority --name chromium_debug chromium_debug -c "--no-sandbox"EDIT: Chromium does not appear to have this issue when following this post. It even works perfectly fine after switching to |
|
Seems that running electron apps inside Docker has had problems in the past: electron/electron#16892 No open issues, though. The person who entered that bug didn't come back and update it for more recent versions of Electron. I think it might be time for some of you in this thread to assemble a simple repro with just basic Electron instead of Signal Desktop, and then we can pursue a fix from the Electron folks. And, one thing you might try is updating Electron to 8.1.x or 9.x to see if that makes a difference. |
|
Hmm. I'm not set up to do full builds of electron, but I'm happy to test builds against newer versions of electron if that helps. I assume there was an electron upgrade between 1.31.0 and 1.32.1 (which we could at least use as info for an upstream bug?). Indeed, no combo of --disable-gpu and --disable-software-rasterizer changed anything for me. |
|
Sure, no need to do builds of Signal Desktop or Electron. It would be valuable for is if you run plain Electron, no user-land code, in that same configuration - the dockerfile listed here might be an interesting starting point: electron/electron#16892 |
Hi, My context is:
I ssh into the linux machine (ssh -Y) so I can get terms on the freebsd desktop. I was able therefore to use signal via the freebsd-desktop. This used to work. Now I get the signal window with a blank screen. If I run signal-desktop on the linux machine locally, signal works as expected. Maybe some issue with xorg? electron is not installed on the linux machine - it was installed as per the instructions on the signal website. |
|
Right, I also don't have an electron (or nvm) toolchain installed anywhere. We could at least open an issue upstream so they can advise - what version of electron is used in signal-desktop so that I can do so? |
|
Currently 8.0.3: https://github.com/signalapp/Signal-Desktop/blob/development/package.json#L209 Soon to be 8.1.1. |
3 tasks
|
Reported upstream as electron/electron#22775 so for those who also see this issue it likely makes sense to track that/help debug there. |
|
Same thing happened to me. If I downgrade the package to 1.31.0, everything works again. Something definitely changed in 1.32.1 that makes it not work. |
|
|
|
i have the same issue running in lxc container, after upgrade to deb 1.31.1 i have just white(ish) screen getting few warnings on run after downgrade to 1.31.0 and "chmod 4755 /opt/Signal/chrome-sandbox" it works again |
The answer why's that, is just in the comment above yours:
So we already know that The corresponding upstream issue was also already mentioned:
|
|
> `v1.31.0` was on Electron `6.1.4` and `v1.32.1` is on Electron `8.0.3`.
So we already _know_ that `v1.31.0` and lower is working.
Maybe it would make sense to try and bisect to find which version of
Electron from 6.1.4 to 8.0.3 causes this?
I'm wondering why there was such a huge version bump in the first
place.
The corresponding upstream issue was _also_ already mentioned:
> Reported upstream as
> [electron/electron#22775](electron/electron#22775)
> so for those who also see this issue it likely makes sense to track
> that/help debug there.
Just filing a bug with electron, that Signal doesn't work with the new
electron, isn't going to get a lot of traction. Why would electron devs
dig into why signal isn't working right? It seems like Signal desktop
devs should work with the electron people to debug this, rather than
just throw it at them and say 'it doesn't work'... at minimum bisect to
try to find where the issue actually arrived, which would help narrow
down where the actual problem is.
|
Yes it would. Feel free to do so. 👍
Because it is an
Excatly, there's even a good starting point for an electron Dockerfile, as mentioned earlier by Scott. |
How can I downgrade to v.1.31.0 ? signal-desktop running on Mint (ubuntu-derived) |
|
did you install using their repo? if yes, then just |
|
awesome! I know about freebsd, but almost nothing about apt/linux, so thanks for this |
unfortunately this no longer works. Today, I had found out that somehow signal had auto-updated itself to 1.32 and now running apt update was asking me to update it to 1.33. So tried running signal before apt. White screen again, so next ran apt update. Same white screen. So deinstalled signal desktop and ran this: the result: Reading package lists... Done How can I get back to 1.31, and (I realise this second question isn't really a signal question), how can I make it stop updating until the signal/electron problem is fixed? thanks |
scottnonnenberg-signal
changed the title
|
Thanks to @wpeckr we have a workaround for this issue. Start Signal Desktop with the Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1048186 |
|
I found that the following worked:
```
QT_X11_NO_MITSHM=1 _X11_NO_MITSHM=1 _MITSHM=0 /usr/bin/signal-desktop
```
from https://bugs.chromium.org/p/chromium/issues/detail?id=1048186#c8
…--
micah
|
|
I was running into this issue when running electron in docker. It appears that chromium is trying to use shared memory, but fails and doesn't fall back correctly, resulting in a blank screen. @micah's solution works because the environment variable Other possible solutions are:
For those curious as to why these solutions work/want more information to dig deeper into the bug, I have a more in-depth explanation here: electron/electron#22775 (comment) |
|
now on v. 5.32, the trick is to use --in-process-gpu :/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After upgrading from v1.31.0 (installed via https://updates.signal.org/desktop/apt) to v1.32.1 the conversation pane no longer loads and instead a window appears that is only white. Downgrading to v1.31.0 fixed the issue again.
debug log after downgrade: https://0bin.net/paste/LmuKEcI-Ku86x49d#UdKkhFyNi-p6ANbJKh8XHbSfoyky0GCkgJdoThwrcG1
debug log on 1.32.1: https://0bin.net/paste/461AypIFQ395vsCg#uvcoo+SXlr2zJwiZgrz-6OjD6ixcbnJv6v9xgq/4XUF
The client is running inside an LXC container (with /dev/shm mounted and an init running) with X available via a /tmp/.X11-unix bind-mount.
The text was updated successfully, but these errors were encountered: