refactor: remove explicit ozone-platform default#2506
Open
IsmaelMartinez wants to merge 1 commit into
Open
Conversation
Contributor
📦 PR Build Artifacts✅ Build successful! Download artifacts: 🐧 Linuxx86_64 (447.77 MB) - Contains: .deb, .rpm, .tar.gz, .AppImage arm64 (438.03 MB) - Contains: .deb, .rpm, .tar.gz, .AppImage armv7l (415.86 MB) - Contains: .deb, .rpm, .tar.gz, .AppImage 🍎 macOSx86_64 (129.21 MB) - Contains: .dmg 🪟 Windowsx86_64 (109.58 MB) - Contains: .exe installer 📝 Note: Snap packages (.snap) are built in a separate workflow 🕐 Last updated: 2026-05-16 07:23 UTC |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request changes the default display backend from forcing X11 (--ozone-platform=x11) to automatic detection (--ozone-platform=auto) in the package configuration. Correspondingly, the documentation and troubleshooting guides have been updated to reflect that Chromium will now pick the best backend based on the session, while still providing instructions for manual overrides if issues occur. I have no feedback to provide as there were no review comments.
Contributor
📦 PR Snap Build Artifacts✅ Snap builds successful! Download artifacts: 🐧 Linux Snap Packagesx86_64 (110.69 MB) arm64 (107.51 MB) armv7l (101.54 MB) 📝 Note: Other package formats (.deb, .rpm, .AppImage, .dmg, .exe) are built in the main workflow |
This was referenced May 7, 2026
|
Hmm, using 'auto' or 'wayland' makes the app unlaunchable. GNOME 49.5. |
2 tasks
IsmaelMartinez
added a commit
that referenced
this pull request
May 7, 2026
#2509) * feat: default ozone-platform to auto instead of x11 Let Chromium pick the rendering backend per session (Wayland on Wayland, X11 elsewhere) rather than forcing XWayland everywhere. Users hitting Wayland regressions can still override with --ozone-platform=x11 on the command line or in their .desktop file. Updates the deb/rpm/AppImage and snap executableArgs in package.json and refreshes the troubleshooting + configuration docs to match the new default. The XWayland runtime detection in commandLine.js is unchanged: it still triggers when the user explicitly passes --ozone-platform=x11. * docs(roadmap): capture 2026-05-07 ozone-platform default reset session Bump the Last Updated date and status line, extend the Wayland Compatibility section with PR #2506 and tracking issue #2508 context, and add a session outcomes block summarising today's PR open, tracker creation, and the four targeted pings (#2486, #2345, #2383, #2094). Closes nothing; the actual default change ships in #2506. --------- Co-authored-by: Claude <noreply@anthropic.com>
Owner
Author
|
Hi @isorropisths , can you provide some logs and more info? this is mostly a PoC to see if it is better to default to x11 (as we do now) or move to auto (as some people are requesting). I am surprised GNOME 49.5 is not working under wayland as GNOME 49 I think is wayland only. Can you clarify on the "unlaunchable"? Thanks again |
|
With |
Same here on Fedora 43 GNOME (Wayland, Intel Iris Xe). --ozone-platform=auto causes a fatal crash: Switching to --ozone-platform=wayland fixed both screenshare and camera for me but only after switching from the snap to the RPM package. The snap bundles an old GNOME platform (gnome-3-28-1804) with Mesa Also confirming your suggestion with --ozone-platform-hint=auto is likely the correct flag here. It tells Electron to auto-detect the appropriate backend (Wayland or X11) rather than forcing one, which is what |
|
And just a note: With |
Owner
Author
|
Looks like I made a couple of mistakes and chrome and electron using the same flags for different things is confusing this even more. Chrome removed the --ozone-platform-hint a few versions ago and that caused a lot of issues when we moved to the electron version using it. (in the 2.7.x release - electron 38). As such we had to build for --ozone-platform=x11 . This was because they changed this platform to auto https://www.electronjs.org/docs/latest/breaking-changes#planned-breaking-api-changes-380 A couple of days ago I asked to test with --ozone--platform=auto for some reason that fixes the issue in #2486 (comment) but as you can see there is a typo (the double -- in the middle) what confused me and only saw now. That message did confused me, as it reads like that value is available... and the cross-distro tests that I got to pick this issues only pull from main, so they didn't report any issues... as main still uses the x11 flag. Anyway, thanks a lot for your tests. I will just remove that flag (as we had before 2.7.x) and see if the "auto" ozone-platform chrome ships with handles the x11/wayland/xwayland correctly. It might fail, and if it does, then I can also include electron 42 update (just released) in case that ones finally fixes it. Thanks a lot for testing and apologies for the confusion. |
IsmaelMartinez
changed the title
3 tasks
IsmaelMartinez
added a commit
that referenced
this pull request
May 8, 2026
PR #2509 ("docs(roadmap): capture 2026-05-07 ozone-platform default reset session") accidentally bundled a package.json change that flipped the flag from =x11 to =auto. =auto is not a valid value for --ozone-platform — Chromium aborts with `FATAL:ui/ozone/platform_selection.cc:46 Invalid ozone platform: auto`, making every build cut from main since 2026-05-07 unlaunchable on every distro and packaging format. Restore the working =x11 default. The proper "remove the flag entirely and let Chromium auto-detect per session" direction is being handled separately on #2506; this is the minimum patch to keep main releasable until that lands. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
IsmaelMartinez
force-pushed
the
claude/ozone-flag-auto-nWlFb
branch
from
9bf50cb to
1f98e9c
Compare
Owner
Author
|
@farajaahdaf / @dannytrunk , I have not removed the flag altogether (like we use to do pre-electron-38) . Can you pick the newest version of it (same comment). Again we might need to upgrade electron to 42, but the smoke test (in all distros) did build fine this time (with this not just main). Thanks in advance! |
|
Looks like it's working fine for me now. At least no more crashes. |
Owner
Author
|
@isorropisths and @farajaahdaf , are you able to test that new version? @dannytrunk , can you provide OS/Distro version where you did test this? Thanks in advance! |
|
@IsmaelMartinez Debian 13 with Gnome |
|
I am also experiencing the issue with trying to share giving an error regarding unable to access camera. I installed the linked build from the comment above (downloaded, then installed the snap with snap install --dangerous ./path-to-file) I am running on a For extra possible confusion and edge case causing, my only active display is a 4k widescreen over a usbc dock -> HDMI. The logs I get when I run the application from the CLI are below. After the segfault it crashes. Happy to provide any additional information, run commands, whatever. I appreciate your efforts, this is pretty far outside of my wheelhouse! |
Owner
Author
|
Thanks for testing. The Two quick tests to confirm before I decide whether to hold the snap part of this PR back:
Appreciate the help. |
PrepI uninstalled the (publicly available) snap with Same from a few days agoI still had the file from yesterday, so I reinstalled it with: then ran it: The app started, and I logged in successfully, started a test call, but it was unable to detect any microphones, my camera, and sharing was non-functional in the same way (Share button available, but when I click it, camera not available error in a popup). Running the AppImageI am unfamiliar with the details of AppImages, but google tells me they are run like executables. FirstSo I installed libfuse SecondI am not entirely certain where to go from there honestly. Going to reboot and see if something needs to get rebuilt/rerun after my install of libfuse2 and give it another shot though. Please let me know what else I can do to help. |
|
No change after reboot. |
2 tasks
IsmaelMartinez
added a commit
that referenced
this pull request
May 15, 2026
…e x11 default (#2547) * docs(notifications,wayland): GNOME workaround for #2411, restore ozone x11 default Documents the GNOME notification-disappearance workaround confirmed on #2411 (notificationMethod electron plus timeoutType never), and corrects four references that claimed the shipped ozone-platform default is auto. package.json lines 102 and 146 still ship --ozone-platform=x11 on every Linux packaging format; PR #2506 is the queued migration to auto and has not landed yet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: address Gemini feedback on PR #2547 Switch "centre" to "center" to match the existing American-English convention in the docs, and drop a redundant "X11 remains the default" clause from the Wayland admonition. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The X11 default was added in v2.7.4 to mask Electron 38 era native Wayland regressions. Two upstream changes mean we no longer need to ship an explicit backend at all: Electron 38 deprecated ELECTRON_OZONE_PLATFORM_HINT (the env var family DISABLE_WAYLAND belonged to) because Chromium 140 made --ozone-platform-hint default to "auto", and the Chromium CL behind that (crrev.com/c/6775426) lets the renderer pick Wayland on Wayland sessions and X11 otherwise without any flag. Drop both executableArgs entries from package.json. Users who hit a regression can still pin x11 or wayland explicitly, documented in troubleshooting.md and configuration.md. The runtime XWayland detection in commandLine.js is intentionally unchanged: isXWayland still triggers only on an explicit --ozone-platform=x11, so the wayland.xwaylandOptimizations opt-in path is preserved for users who need it. Update cross-distro test docs and the entrypoint comment to reflect that the AppImage no longer ships a default. start-wayland.sh continues to force --ozone-platform=wayland for native Wayland tests; start-x11.sh and start-xwayland.sh launch with no flag and rely on Chromium's session-based selection. Add pr_number and app_url inputs to the cross-distro smoke workflow so the matrix can be triggered against a PR build's AppImage rather than the latest release. Inputs are validated and consumed only via env vars to avoid workflow injection. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
IsmaelMartinez
force-pushed
the
claude/ozone-flag-auto-nWlFb
branch
from
1f98e9c to
be857d4
Compare
|
Geek0x0
pushed a commit
to Geek0x0/teams-for-linux
that referenced
this pull request
May 19, 2026
…inez#2511) PR IsmaelMartinez#2509 ("docs(roadmap): capture 2026-05-07 ozone-platform default reset session") accidentally bundled a package.json change that flipped the flag from =x11 to =auto. =auto is not a valid value for --ozone-platform — Chromium aborts with `FATAL:ui/ozone/platform_selection.cc:46 Invalid ozone platform: auto`, making every build cut from main since 2026-05-07 unlaunchable on every distro and packaging format. Restore the working =x11 default. The proper "remove the flag entirely and let Chromium auto-detect per session" direction is being handled separately on IsmaelMartinez#2506; this is the minimum patch to keep main releasable until that lands. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Geek0x0
pushed a commit
to Geek0x0/teams-for-linux
that referenced
this pull request
May 19, 2026
… restore ozone x11 default (IsmaelMartinez#2547) * docs(notifications,wayland): GNOME workaround for IsmaelMartinez#2411, restore ozone x11 default Documents the GNOME notification-disappearance workaround confirmed on IsmaelMartinez#2411 (notificationMethod electron plus timeoutType never), and corrects four references that claimed the shipped ozone-platform default is auto. package.json lines 102 and 146 still ship --ozone-platform=x11 on every Linux packaging format; PR IsmaelMartinez#2506 is the queued migration to auto and has not landed yet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: address Gemini feedback on PR IsmaelMartinez#2547 Switch "centre" to "center" to match the existing American-English convention in the docs, and drop a redundant "X11 remains the default" clause from the Wayland admonition. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The X11 default added in v2.7.4 was a workaround for Electron 38 era native Wayland regressions. With Chromium 140 the
--ozone-platform-hintswitch defaults toautoupstream (crrev.com/c/6775426), and Electron 38 deprecated the matchingELECTRON_OZONE_PLATFORM_HINTenv var (planned breaking change) on the basis that Chromium does the right thing on its own. The cleanest end-state for us is to ship no explicit--ozone-platformvalue and let Chromium pick the backend per session.This PR drops both
executableArgsentries frompackage.json(the deb / rpm / AppImage block and the snap block). Users who hit a Wayland-specific regression can still pin--ozone-platform=x11or force native Wayland with--ozone-platform=waylandfrom the command line or their.desktopfile; both overrides are documented.The runtime XWayland detection in
app/startup/commandLine.jsis intentionally unchanged:isXWaylandstill triggers only when the user explicitly passes--ozone-platform=x11, so thewayland.xwaylandOptimizationsopt-in path keeps working for users who need it.What this means per Electron baseline
On Chromium 140+ (Electron 42+) the implicit
--ozone-platform-hint=autodoes the work and Wayland sessions get a native Wayland renderer for free.On the current Electron 41 / Chromium ~138 baseline shipping in 2.9.x,
autois not yet the implicit default, so removing the flag returns the app to whatever Chromium's compiled-in default is on each platform. The cross-distro smoke matrix is the source of truth here.Cross-distro testing
The smoke workflow now accepts a
pr_number(orapp_url) input viaworkflow_dispatch, so this PR's build can be exercised across the full 3 distros × 3 display servers matrix without waiting for a release. To run it manually:Inputs are validated (
pr_numbermust be a positive integer) and consumed only via env vars in the workflow run script to avoid command injection.tests/cross-distro/scripts/entrypoint.shand the README have been updated so the comments no longer claim--ozone-platform=x11is baked into the AppImage.start-wayland.shcontinues to force--ozone-platform=waylandexplicitly for the Wayland matrix entry;start-x11.shandstart-xwayland.shlaunch with no ozone flag and let Chromium select the backend.Test plan
cross-distro-smoke.ymlwithpr_number=2506, confirm all 9 matrix entries pass--ozone-platform=x11on a Wayland session and confirmwayland.xwaylandOptimizationsstill behaves as before--ozone-platformvalue in their.desktopExec=linesTracking
Community testing for this default change is being gathered in #2508.
Supersedes the previous direction in this PR which tried to switch to
--ozone-platform=auto. That value is not accepted byui/ozone/platform_selection.ccand FATAL-crashed the launcher; the correct expression of the same intent is--ozone-platform-hint=auto, but since Chromium 140 makes that the implicit default anyway, removing the flag entirely is cleaner than carrying a hint that becomes redundant on the next Electron bump.Generated by Claude Code