Trace the root cause to Electron's init order: Ozone platform selection
fires in C++ PreEarlyInitialization() and the chosen platform is
memoized in ui/ozone/platform_selection.cc's g_selected_platform
static. Any app.commandLine.appendSwitch() from main.js runs in
PostEarlyInitialization() — after the memoization, so the write is
correct but the read has already happened. Primary source: electron
PR #48301 diff + Chromium ui/ozone/platform_selection.cc.
This confirms the argv wrapper is structurally the only fix available
from outside the Electron binary. Also documents why the two
lower-friction alternatives don't work:
- ELECTRON_OZONE_PLATFORM_HINT env var was removed as dead code in
Electron 39 (PR #47983).
- Setting XDG_SESSION_TYPE=x11 via snapcraft.yaml environment: would
work for Ozone but would fool IdleTimeHandler, silently breaking
GNOME Wayland idle detection.
Confidence in the mechanism hypothesis is raised from ~40% to ~85%.
Residual unknown: whether GPU child-process CommandLine inheritance
exposes a late appendSwitch to subsystems other than Ozone. Not
verified from source; does not change the shipping recommendation.
Related: issue #7270.
Address findings from code-reviewer + debugger-assistant +
refactor-specialist multi-review on 8e1c47ebc2:
- afterPack: read wrapper source before rename; on writeFile failure,
roll the rename back so a broken intermediate state can't ship a
package with no launcher. Strengthen idempotency check to require a
shebang at binPath (both files alone no longer counts as "installed").
- wrapper: gate the X11 injection on \$SNAP_NAME = "superproductivity",
not just \$SNAP set. An xdg-open from a sibling snap (e.g. Firefox)
leaks \$SNAP into the child env, which previously would have silently
forced XWayland on .deb/.rpm users. Derive BIN_DIR from \$SNAP
directly when we are our snap, avoiding fragile \$0 resolution
through snapd's wrapper chain. Stop argv scanning at -- so positional
args that resemble --ozone-platform aren't misread as a user override.
- app-control: point app.relaunch() execPath at the sibling shell
wrapper instead of the default process.execPath (which is the renamed
ELF and would bypass the flag injection on a relaunched Snap+Wayland
instance).
- Move build/snap-wrapper.sh -> build/linux/snap-wrapper.sh to match
the existing build/linux/ layout convention.
- Update research doc §18 to reflect the tightened predicate and the
relaunch fix.
Field reports on issue #7270 (v18.2.4 / v18.2.5) show that
app.commandLine.appendSwitch('ozone-platform','x11') is not equivalent
to the CLI flag on Snap+Wayland: Chromium's Ozone init dlopens
libEGL/libgbm on the core22 Mesa path before the switch is honored and
segfaults under host-vs-snap Mesa ABI drift, while the same flag on
argv consistently works.
Install an afterPack hook that renames the Electron binary and drops a
shell wrapper at the original name. The wrapper injects the flag into
argv only when \$SNAP is set AND the session is Wayland — non-Snap
targets (AppImage, .deb, .rpm) and X11 sessions pass through untouched.
Matches the mechanism used by snapcrafters/signal-desktop and
snapcrafters/mattermost-desktop.
See docs/research/snap-wayland-gpu-fix-research.md §18 for the full
evidence trail, drawbacks, validation plan, and removal conditions.
7-reviewer multi-review (6 Claude focus-agents + Codex CLI) over the
cherry-picked PR #7273 diff, plus 5 parallel research agents on Mesa
mechanism, Chromium flag behavior, peer-app field data, core22→core24
cost, and marker-timing semantics.
§17 captures: findings that changed the PR (now shipped in the
previous commit), disagreements worth noting (Codex W-C1 vs. three
independent flag-pair sources), validated decisions (APP_READY signal,
Snap config shape, novelty of the crash-loop mechanism), deferred
scope (pre-flight probe, core24 migration, forensic listener,
TOCTOU hardening), and confidence deltas.
Adds 14 new references (Mesa commit, libgbm ABI instability,
peer-app issues on Ubuntu 25.10, Canonical core24 migration docs,
electron-builder#8548, Obsidian launcher) tying each to the §17
claim it supports.
The "PR #7273 was closed" paragraph predates the two post-v18.2.4
field reports in §16. Updated to acknowledge the revisit condition
explicitly: reopen only if a real report came in that X11 widening
didn't rescue. §16 documents two such reports (Intel/Ubuntu 24.04 and
AMD/Ubuntu 25.10), both showing #7266's guard firing correctly and
still not rescuing the user. PR #7273's mechanism is no longer
speculative — it rescues the population #7266 provably does not.
Also wrap DISPLAY_COMPOSITOR in backticks on line 846 to prevent
prettier from parsing underscores as an italic span across lines.
Second post-v18.2.4 field report (Ubuntu 25.10 + AMD Raphael) replicates
DerEchteKoschi's failure pattern (Ubuntu 24.04 + Intel Arrow Lake-P):
#7266's guard fires, MESA-LOADER fails on gbm/dri_gbm.so, GPU process
segfaults in a loop regardless of ozone platform. Confirms the tail is
driven by host-Mesa/core22-runtime drift, not GPU vendor or generation.
Changes in §16:
- Intro + Environments: switch to n=2 framing with per-reporter blocks.
- What the log proves: clarify shared pattern; flag nekufa's
`--ozon-platform` typo (short-circuit in start-app.ts:73-75 only
matches `--ozone-platform`, so the log reflects the programmatic path).
- Scope table: drop "Arrow Lake, newer" parenthetical — generic
drift row covers any Ubuntu ≥ 24.04 with core22 mismatch.
- PR #7273 framing + core24 urgency cite n=2 evidence.
- Open question: note nekufa's typo disqualifies from CLI vs
appendSwitch question.
- Actionable outcomes split reply-to-thread per reporter; add
item 6 for separate Ctrl+Shift+X issue.
- Confidence: arch-specificity upgraded Medium → High.
- References: add both comment permalinks.
Prettier formatting applied.
First post-release report on PR #7266 (v18.2.4): X11 widening fires
but doesn't rescue user on Ubuntu 24.04 + Intel Arrow Lake-P. Mesa
DRI still fails, GPU process segfaults in a loop. Lowers the 95%
estimate, promotes --disable-software-rasterizer to must-ship, and
upgrades core24/gpu-2404 migration urgency to 18.3.
Follow-up to issue #7270 and the now-closed PR #7273. Extends the
existing research doc with four new sections based on multi-agent
research, verification passes, and empirical reporter confirmation.
- §12: PR #7273 GPU startup guard framing and mechanism analysis.
- §13: Deepened research on Chromium/Electron/Mesa correctness, prior
art for crash-loop startup markers (Firefox recent_crashes, Chromium
in-process GpuMode stack, BugSnag/Sentry patterns), testing strategy
with concrete spec proposal, edge cases, and long-term strategy.
- §14: Verification pass findings (four parallel agents) — corrections
applied to §12 (v18.2.3 timeline, --disable-gpu wording), rejected
claims with evidence, outstanding attribution fixes.
- §15: Final PR re-evaluation — including why PR #7273 was closed in
favor of #7266 after the reporter empirically confirmed that
--ozone-platform=x11 resolves their launch failure on Ubuntu 22.04.
Keeps the research available for the next time this class of failure
surfaces (future Chromium bumps, Mesa ABI drift on core24/gpu-2404,
Flatpak packaging, etc.).
* docs(research): add Snap + Wayland GPU init failure research
Synthesizes root cause (Mesa ABI drift in gnome-42-2204), scope,
peer-app consensus, and ranked options. Recommends widening the
existing Snap-gated --ozone-platform=x11 guard in start-app.ts to
cover Snap + Wayland sessions, with core24 + gpu-2404 migration
as the long-term fix.
https://claude.ai/code/session_01Hu6EP7Xux9JRvGGGKpBfwm
* docs(research): correct electron timing and soften unverified peer claims
* fix(electron): force X11 on Snap Wayland to avoid Mesa ABI drift
The existing Snap-only X11 fallback triggered only when $SNAP/gnome-platform
was empty. In practice gnome-platform is populated but its Mesa can drift
out of ABI sync with Electron's bundled libgbm, producing
"Failed to get system egl display" and a GPU process respawn loop on
Wayland sessions. Widen the guard to also fire when the session is
Wayland (XDG_SESSION_TYPE=wayland or WAYLAND_DISPLAY set). X11/GLX
avoids the failing Wayland EGL init path entirely while preserving
hardware acceleration.
Refs: electron-builder#9452, super-productivity#5672,
forum.snapcraft.io #40975, #49173https://claude.ai/code/session_01JNxazJmDhpMp9UYV6SqnBG
* refactor(electron): address review feedback on Snap X11 force
- Handle space-separated `--ozone-platform wayland` override in addition
to the `=` form; tighten the argv scan to reject accidental substring
matches (e.g., arg values that happen to contain `--ozone-platform=`).
- Enrich the log line with raw XDG_SESSION_TYPE and WAYLAND_DISPLAY
values to make user-reported triage faster.
- Tighten comment: correct "X11/GLX" to "X11 ozone backend" (modern
Chromium uses EGL on X11), clarify the root cause as Mesa version
drift rather than bundled-library ABI drift, broaden the loss list
beyond fractional scaling, and move issue references to the commit
body per CLAUDE.md guidance.
Follow-ups flagged but not addressed here: possible interaction with
`allowNativeWayland: true` in electron-builder.yaml, GPU cache keyed
by effective ozone platform, and the longer-term core24 migration
already in docs/long-term-plans/electron-upgrade-to-v40.md.
Refs: electron-builder#9452, super-productivity#5672,
forum.snapcraft.io #40975, #49173https://claude.ai/code/session_01JNxazJmDhpMp9UYV6SqnBG
* docs(research): verify peer-app claims, correct SP electron timing
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs(research): add recurring events industry standards analysis
Comprehensive research comparing Super Productivity's recurring task
implementation against RFC 5545 RRULE standard and major applications
(Google Calendar, Todoist, Things 3, TickTick).
Key findings:
- Current implementation covers basic patterns but lacks nth weekday,
last day of month, and end conditions (COUNT/UNTIL)
- Recommends adopting rrule.js library for RFC 5545 compliance
- Proposes incremental migration path preserving existing functionality
- Notes "after completion" mode as competitive advantage to preserve
https://claude.ai/code/session_01Rhuxtn9JKKhh4J3iLApaWX
* docs(research): add gap analysis and implementation plan for recurring events
Gap analysis compares current TaskRepeatCfg model against RFC 5545 RRULE
and major applications (Google Calendar, Todoist, Things 3, TickTick).
Implementation plan details 4-phase approach:
- Phase 1: Add rrule.js, create DST-safe wrappers
- Phase 2: Enable new patterns (nth weekday, last day, end conditions)
- Phase 3: Lazy migration strategy
- Phase 4: Natural language display, iCal export
https://claude.ai/code/session_01Rhuxtn9JKKhh4J3iLApaWX
---------
Co-authored-by: Claude <noreply@anthropic.com>
