SUMMARY 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. STEPS TO REPRODUCE 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`) OBSERVED RESULT 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. EXPECTED RESULT The browser window should come up as it does on X11. SOFTWARE/OS VERSIONS 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) ADDITIONAL INFORMATION 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
Can reproduce with Opera browser on neon unstable.
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)
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.
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.
If you type "KWin" into krunner and open the debug console, is the window shown in there?
(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.
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.
I think this happens when you enable use system borders and maximize chromium.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1764
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
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 https://invent.kde.org/plasma/kwin/commit/53e3e87681ddfb92a6676f575bc1dd2ccf2530c2
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1765
This also happens when you maximize when using csd.
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 table. 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 https://invent.kde.org/plasma/kwin/commit/acb0683e0da532e62cb7942408f9c5edc692091a
(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
Seeing this again, spontaneously just started using Arch, Plasma 5.27.5, Frameworks 5.106.0, QT 5.15.9 . Tested it with Brave, Chromium, Evolution email and Dolphin. Icon goes orange but won't open the window from the taskbar, unless the browser isn't open or launched.
This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Thank you!