Bug 445259

Summary: Several Chromium-based browsers suddenly fail to bring up their browser windows on Wayland
Product: kwin Reporter: phrxmd <philipp.reichmuth>
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Severity: normal CC: asturm, bugseforuns, indecisiveautomator, nate, saiarcot895, sam, samuelsumukhreddy, sokann, stoffepojken, tagwerk19, viktor_jaegerskuepper, xaver.hugl
Priority: NOR    
Version: 5.23.2   
Target Milestone: ---   
Platform: openSUSE RPMs   
OS: Linux   
Latest Commit: Version Fixed In: 5.24

Description phrxmd 2021-11-10 08:51:51 UTC
Chromium-based browsers are unable to bring up their browser windows on Wayland (tested with Chromium, Brave and Edge). The browser processes are running, but no browser window appears.

This started happening since yesterday, with no changes to the system configuration or packages. The problem persists after a logout and reboot.

As it started happening on three separate browsers, and the package versions for all three browsers are unchanged, and Brave and Edge are self-contained, I believe there could be an issue related to the compositor. 

1. Launch browser with `--enable-features=UseOzonePlatform --ozone-platform=wayland`:
   chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
   (substitute `brave-browser` or `microsoft-edge-dev` for `chromium`) 

The browser processes come up as they do on X11, but no browser window appears. When I hit Ctrl+C in the command line, they are terminated.

The browser window should come up as it does on X11.

Operating System: openSUSE Tumbleweed 20211107
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-1-default (64-bit)
Graphics Platform: Wayland

Chromium: 95.0.4638.69-1.1 (OpenSUSE RPM) 
Brave: 1.31.88-1 (OpenSUSE RPM)
Edge: 97.0.1069.0-1 (OpenSUSE RPM) 

Command line output:
chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
[6687:6687:1110/092447.136492:ERROR:browser_main_loop.cc(269)] Gdk: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed
[6687:6687:1110/092447.246910:ERROR:cursor_loader.cc(115)] Failed to load a platform cursor of type kNull
[6732:6732:1110/092447.576224:ERROR:gpu_init.cc(453)] Passthrough is not supported, GL is egl, ANGLE is 
[6732:6732:1110/092447.580413:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[6687:6742:1110/092747.721888:ERROR:chrome_browser_main_extra_parts_metrics.cc(230)] crbug.com/1216328: Checking Bluetooth availability started. Please report if there is no report that this ends.
[6687:6742:1110/092747.721905:ERROR:chrome_browser_main_extra_parts_metrics.cc(233)] crbug.com/1216328: Checking Bluetooth availability ended.
[6687:6742:1110/092747.721909:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)] crbug.com/1216328: Checking default browser status started. Please report if there is no report that this ends.
[6687:6742:1110/092747.821040:ERROR:chrome_browser_main_extra_parts_metrics.cc(240)] crbug.com/1216328: Checking default browser status ended.

Output from `ps ax`:
> ps ax | grep chrom
 6687 pts/2    Sl+    0:02 /usr/lib64/chromium/chrome --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-crashpad
 6695 ?        Sl     0:00 /usr/lib64/chromium/chrome_crashpad_handler --monitor-self --monitor-self-annotation=ptype=crashpad-handler --database=/home/username/.config/chromium/Crash Reports --annotation=channel=stable --annotation=lsb-release=openSUSE Tumbleweed --annotation=plat=Linux --annotation=prod=Chrome_Linux --annotation=ver=95.0.4638.69 --initial-client-fd=229 --shared-client-connection
 6698 pts/2    S+     0:00 /usr/lib64/chromium/chrome --type=zygote --no-zygote-sandbox --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --enable-crashpad
 6700 ?        S      0:00 /usr/lib64/chromium/chrome_crashpad_handler --no-periodic-tasks --monitor-self-annotation=ptype=crashpad-handler --database=/home/username/.config/chromium/Crash Reports --annotation=channel=stable --annotation=lsb-release=openSUSE Tumbleweed --annotation=plat=Linux --annotation=prod=Chrome_Linux --annotation=ver=95.0.4638.69 --initial-client-fd=4 --shared-client-connection
 6702 pts/2    S+     0:00 /usr/lib64/chromium/chrome --type=zygote --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --enable-crashpad
 6704 pts/2    S+     0:00 /usr/lib64/chromium/chrome --type=zygote --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --enable-crashpad
 6732 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=gpu-process --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --gpu-preferences=UAAAAAAAAAAgAAAYAAAAAAAAAAAAAAAAAABgAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAQAAAAAQAAAAgAAAAAAAAAEAAAAAAAAAAAAAAAAwAAAAgAAAAAAAAACAAAAAAAAAA= --shared-files
 6733 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --lang=de --service-sandbox-type=none --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --shared-files=v8_context_snapshot_data:100 --enable-crashpad
 6735 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=utility --utility-sub-type=storage.mojom.StorageService --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --lang=de --service-sandbox-type=utility --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --change-stack-guard-on-fork=enable --shared-files=v8_context_snapshot_data:100
 6759 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=renderer --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --display-capture-permissions-policy-allowed --change-stack-guard-on-fork=enable --ozone-platform=wayland --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=6 --shared-files=v8_context_snapshot_data:100
 6761 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=renderer --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --display-capture-permissions-policy-allowed --change-stack-guard-on-fork=enable --ozone-platform=wayland --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=5 --shared-files=v8_context_snapshot_data:100
 6823 pts/2    Sl+    0:00 /usr/lib64/chromium/chrome --type=renderer --enable-crashpad --crashpad-handler-pid=0 --enable-crash-reporter=,stable --display-capture-permissions-policy-allowed --change-stack-guard-on-fork=enable --ozone-platform=wayland --field-trial-handle=1093270205260396699,6503610067434351146,131072 --enable-features=UseOzonePlatform --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=7 --shared-files=v8_context_snapshot_data:100
 6853 pts/1    S+     0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox chrom

I reported it to the Brave and Chromium communities, respectively:
Brave: https://community.brave.com/t/brave-window-not-coming-up-on-wayland-even-though-browser-is-running/299539
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1268758
Comment 1 Patrick Silva 2021-11-10 14:55:05 UTC
Can reproduce with Opera browser on neon unstable.
Comment 2 Sok Ann Yap 2021-11-12 05:43:59 UTC
This started happening to me after upgrading to kwin-5.23.3.

Chromium works fine on ozone/wayland again, after backing out these 2 commits:
- e2f9f35c (wayland: Check workspace position when preferred deco mode changes)
- ceec4e50 (wayland: Fix wayland windows growing after toggling decorations)
Comment 3 Viktor Jägersküpper 2021-11-30 20:02:38 UTC
For me this happens when I start Chromium if I closed it in the maximized state. The browser window is displayed normally if it was closed when it was not maximized.
Comment 4 indecisiveautomator 2021-11-30 21:55:31 UTC
Started affecting me in Plasma 5.23.4 with Arch Linux. Worked fine before the update. Chromium/Brave will only open on XWayland with `--gtk-version=4`. It will not work with the Ozone Wayland platform. Electron apps seem to be working fine.
Comment 5 Zamundaaa 2021-12-07 09:39:34 UTC
If you type "KWin" into krunner and open the debug console, is the window shown in there?
Comment 6 Patrick Silva 2021-12-07 10:24:18 UTC
(In reply to Zamundaaa from comment #5)
> If you type "KWin" into krunner and open the debug console, is the window
> shown in there?

in my case with chromium-based Opera browser on neon unstable, no.
Comment 7 phrxmd 2021-12-07 10:39:08 UTC
In my case, after updating to Plasma 5.23.4 I now get the same behaviour as in comment 4.

When starting Chromium from the command line with `chromium --enable-features=UseOzonePlatform --ozone-platform=wayland`, the browser window opens normally (same with Brave and Edge)

After maximizing Chromium, closing the maximized window and starting it again with the same command line command, the window no longer comes up, while the command is running. 

It this state is not visible in the KWin debug console.
Comment 8 Samuel Reddy 2021-12-07 22:31:33 UTC
I think this happens when you enable use system borders and maximize chromium.
Comment 9 Bug Janitor Service 2021-12-08 10:03:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1764
Comment 10 Vlad Zahorodnii 2021-12-08 13:12:43 UTC
The issue is caused by kwin's incorrect handling of xdg-decoration (google chrome initializes its xdg-toplevel surface differently from Qt apps, which triggers some bugs). Not a trivial problem but will try to get it fixed in 5.24
Comment 11 Vlad Zahorodnii 2021-12-08 13:29:25 UTC
Git commit 53e3e87681ddfb92a6676f575bc1dd2ccf2530c2 by Vlad Zahorodnii.
Committed on 08/12/2021 at 13:05.
Pushed by vladz into branch 'master'.

autotests: Make decoration mode change tests more robust

Currently, kwin expects that the xdg-decoration is installed before the
initial commit. However, decoration tests do that after the initial
commit, which makes testMaximizeAndChangeDecorationModeAfterInitialCommit()
silently pass.

On a second look, it seems that the xdg-decoration spec is okay with the
xdg-decoration being created after the first commit (as long as it's
done before the surface is mapped). This needs to be fixed separately.

M  +12   -2    autotests/integration/xdgshellclient_test.cpp

Comment 12 Bug Janitor Service 2021-12-08 14:35:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1765
Comment 13 Samuel Reddy 2021-12-15 08:32:42 UTC
This also happens when you maximize when using csd.
Comment 14 Vlad Zahorodnii 2021-12-15 13:33:57 UTC
Git commit acb0683e0da532e62cb7942408f9c5edc692091a by Vlad Zahorodnii.
Committed on 15/12/2021 at 12:47.
Pushed by vladz into branch 'master'.

wayland: Properly handle async xdg-decoration updates

Currently, if a window switches between SSD and CSD, it is possible to
encounter a "corrupted" state where the server-side decoration is wrapped
around the window while it still has the client-side decoration.

The xdg-decoration protocol fixes this problem by saying that decoration
updates are bound to xdg_surface configure events.

At the moment, kwin sort of applies decoration updates immediately. With
this change, decoration updates will be done according to the spec.

If the compositor wants to create a decoration, it will send a configure
event and apply the decoration when the configure event is acked by the
client. In order to send the configure event with a good window geometry
size, kwin will create the decoration to query the border size but not
assign it to the client yet. As is, KDecoration api doesn't make
querying the border size ahead of time easy. The decoration plugin can
assign arbitrary border sizes to windows as it pleases it. We could change
that, but it effectively means starting KDecoration3 and setting existing
window deco ecosystem around kwin on fire the second time, that's off the

If the compositor wants to remove the decoration, it will send a
configure event. When the configure event is acked and the surface is
committed, the window decoration will be destroyed.

Sync'ing decoration updates to configure events ensures that we cannot
end up with having both client-side and server-side decoration. It also
helps us to fix a bunch of geometry related issues caused by creating
and destroying the decoration without any surface buffer attached yet.

M  +14   -10   autotests/integration/decoration_input_test.cpp
M  +13   -14   autotests/integration/dont_crash_no_border.cpp
M  +7    -1    autotests/integration/effects/popup_open_close_animation_test.cpp
M  +12   -10   autotests/integration/maximize_test.cpp
M  +7    -10   autotests/integration/touch_input_test.cpp
M  +55   -83   autotests/integration/xdgshellclient_test.cpp
M  +8    -8    src/abstract_client.cpp
M  +2    -2    src/abstract_client.h
M  +3    -3    src/x11client.cpp
M  +138  -79   src/xdgshellclient.cpp
M  +15   -1    src/xdgshellclient.h

Comment 15 Vlad Zahorodnii 2021-12-15 13:36:37 UTC
(In reply to Samuel Reddy from comment #13)
> This also happens when you maximize when using csd.

Caused by the same issue.

KWin would still temporarily create a decoration even when using csd because of the way chromium-based browsers initialize. https://bugs.chromium.org/p/chromium/issues/detail?id=1268308