chromium 79 remote display broken

Bug #1857252 reported by mike Bernson
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
chromium (Debian)
Fix Released
Unknown
chromium (Fedora)
Confirmed
Medium
chromium-browser (Ubuntu)
Undecided
Unassigned

Bug Description

Chromium 78 worked and things broke in version 79.

With chromium 79 when using the remote display (ssh for x forward) I get the display forward but only a blank (white) window. Chromiumn does not render anything into the window.

If I am at the console then every thing work normal. Also Firefox does work for remote display. It just chromium 79 that has this problem.

Every thing worked with version 78.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubuntu-release-upgrader-core 1:18.04.36
ProcVersionSignature: Ubuntu 5.0.0-37.40~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-37-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CrashDB: ubuntu
CurrentDesktop: GNOME
Date: Sun Dec 22 14:57:30 2019
InstallationDate: Installed on 2016-07-24 (1246 days ago)
InstallationMedia: Ubuntu-GNOME 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160720)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubuntu-release-upgrader
Symptom: dist-upgrade
UpgradeStatus: Upgraded to bionic on 2018-09-03 (475 days ago)
VarLogDistupgradeTermlog:

Revision history for this message
mike Bernson (mike-mlb) wrote :
affects: ubuntu-release-upgrader (Ubuntu) → chromium-browser (Ubuntu)
Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

Description of problem:

starting Chromium 79 (and also google-chrome-stable 79) through a ssh tunnel gives a blank (white) window. Actually it is possible to click on some buttons if one is able to locate them with the mouse without seeing them.

By Clicking on "Chromium Web Browser" in the top bar of the screen, it is possible to open a new window which is visible, but the window has not loaded any personal configuration (bookmarks, extensions etc.)

Version-Release number of selected component (if applicable):
chromium-79.0.3945.79-1.fc31.x86_64

How reproducible: always

Steps to Reproduce:
1. ssh -X -f user@host "/usr/bin/chromium-browser"
2. a blank (white) window opens
3. click on "Chromium Web Browser" in the top bar of the screen and select "Open a New Window"
4. a normal (visible) chromium window opens, but all personal configuration (bookmarks, extensions etc.) is not loaded

Actual results:
a blank (white) window opens first, it is possible to open a second window but without all personal configuration (bookmarks, extensions etc.)

Expected results:
a visible window is opened and all personal configuration is loaded.

Additional info:
chromium 78 works fine (as it has always done) over an ssh tunnel.

See also https://support.google.com/chrome/thread/23330705?hl=en

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
Revision history for this message
In , tcallawa (tcallawa-redhat-bugs) wrote :

You might want to open a bug with chromium upstream here:

https://bugs.chromium.org/p/chromium/issues/list

The code diff between 78 and 79 is rather large, and I'm not sure where to even start digging into what would cause X11 forwarding to break.

Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

Upstream chromium bug "Issue 1026950: Regression: displaying over ssh forwarded X11 shows only grey window"

https://bugs.chromium.org/p/chromium/issues/detail?id=1026950

according to this, the bug persists also in Google Chrome 80.0.3987.16 beta

Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

Workaround according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949440

Bug seems to be related to MIT-SHM management

Works for me right now as follows:

- on the target machine install gcc and libX11-devel

- download XlibNoSHM.c from above link (at the bottom of the page)

- compile (always on target machine) with
    gcc -shared -fPIC -o XlibNoSHM.so XlibNoSHM.c

- start chrome from the client on the target machine with
   ssh -X -f user@target "LD_PRELOAD='libdl.so ./XlibNoSHM.so' /usr/bin/google-chrome-stable"

Changed in chromium (Debian):
status: Unknown → New
Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

The bug persists with google-chrome-stable-80.0.3987.87-1 , the above workaround still works.

Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

With google-chrome-stable-81.0.4044.129-1.x86_64 it is necessary to add also the option --no-sandbox which makes it quite unsafe to use.

Revision history for this message
In , cesare (cesare-redhat-bugs) wrote :

Just found another workaround, google-chrome-stable-81.0.4044.129-1.x86_64 starts with

ssh -X -f user@target "LD_PRELOAD='libdl.so ./XlibNoSHM.so' /usr/bin/google-chrome-stable --use-gl=swiftshader"

as far as I understand, swiftshader is a "high-performance CPU-based implementation of the Vulkan and OpenGL ES graphics APIs, its goal is to provide hardware independence for advanced 3D graphics ... act as drop-in replacements for graphics drivers" (from GitHub) which could mean in some cases worse graphic performances.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Comments #11 and #12 in the upstream bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=1026950) have suggested workarounds.

Revision history for this message
In , fedora-admin-xmlrpc (fedora-admin-xmlrpc-redhat-bugs) wrote :

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Changed in chromium (Debian):
status: New → Fix Released
Changed in chromium (Fedora):
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.