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>