I don’t think software password managers make sense on monolithic desktop oses, which run everything in the same os image. I use keepassxc on qubes-os, where its in its own vm, and so is everything else. The relevant vm only ever sees the password pasted into it. Unfortunately Qubes uses X11 instead of wayland, so everything in that vm can see it. Browsers for specific contexts get their own vm to minimize that attack surface. The best I can think of is passkeys and keeping your password manager on your phone. Passkeys won’t save you if the os get compromised. Most mobile oses, including ios and android, are better about compartmentalization than monolithic desktop OSes. Graphene is good.

I can add measured Firefox Profiler evidence for the same symptom family: very high CPU in a long conversation, delayed or blank sections while scrolling upward, multi-second input and paint delays, and extremely slow visible message updates. **Environment** * ChatGPT Pro on ChatGPT Web * Firefox 153.0 on Linux Mint, X11/GTK * AMD Ryzen 9 9950X, 16 physical / 32 logical CPUs * 22 August 2026, Europe/Zurich (CEST) * A very long conversation with substantial Markdown and structured content **Reproduction** 1. Reload the affected long conversation. 2. Scroll upward while older sections are progressively restored. 3. Observe sustained CPU use, delayed input/paint, and areas that remain blank for seconds before appearing. 4. Continue the conversation and observe very slow visible response updates. The two strongest retained intervals measured as follows: Scenario | Retained span | Main-thread CPU | One-core utilization | Explicit long tasks | Minor-GC markers | Style markers ---|---|---|---|---|---|--- Reload and upward scroll | 45.361 s | 36.738 s | 80.99% | 6 totaling 1.560 s; max 648 ms | 184,032 | 2,493 Continue and response rendering | 67.199 s | 48.606 s | 72.33% | 310 totaling 45.358 s; max 246 ms; p95 196 ms | 120,836 | 7,625 In the reload/scroll capture, first-party ChatGPT JavaScript appeared somewhere in the stack for 93.90% of sampled main-thread CPU, while extension JavaScript accounted for 0.22%. The continuation capture also recorded 7,102 container-query style updates, 3,096 paint/display transactions, and 678 synchronous-reflow markers. Sampled inclusive stacks repeatedly passed through ChatGPT conversation/display-state work, synchronous state updates, and display-item derivation. The stacks overlap, and minified bundles do not identify one component as the sole root cause. The evidence does show enough first-party main-thread work to delay event handling and painting even on a high-core-count desktop. **Requested investigation / expected behavior** * Window or unmount off-screen turns while preserving scroll position. * On reopen, show completed user-visible reasoning summaries, tool logs, and activity details as lightweight collapsed placeholders; fetch/render them on click and release their DOM/AST/highlighter state when collapsed again. * **Store a safe content-hashed, renderer-versioned presentation representation for completed messages server-side** so a page load does not require every client to reparse all historical raw Markdown. * Maintain Markdown parser checkpoints and open-block state. For appended content, reparse from the nearest affected opener or safe block boundary rather than automatically scanning from the beginning of the message. * **Buffer incoming deltas and commit them at a bounded adaptive cadence** , such as 100–500 ms, with an optional 500–1000 ms low-CPU mode for slower systems. Stop and input controls must remain immediate. * Freeze completed blocks and avoid recomputing a full display list for a small tail update. * Audit synchronous state flushes, style/container-query churn, observers, content-visibility transitions, and scroll anchoring. * Keep scrolling, Stop, and navigation responsive while older turns load. I am not claiming that React alone is the bug, that every completed message is reparsed for every token, or that switching transport to WebSockets would fix rendering. The measured defect is first-party main-thread scaling under long and streaming conversations.

I built a device to measure end-to-end input latency, then used it to find out what actually moves the needle.

If you’re a KDE user who still depends heavily on X11 and is concerned about what happens after Plasma 6.8 drops the X11 session, there is some good news. SonicDE is an emerging X11-focused desktop project based on forked KDE Plasma components with a simple goal: to preserve and enhance KDE’s X11-specific components. Currently, SonicDE includes a customized KWin/X11 fork called sonic-win, Plasma Workspace components, the Silver theme, an SDDM theme, and supporting libraries.

When we first announced the transition to Plasma Wayland, one of Martin's slides from stated, "It's done when it's done!" That talk was 15 years ago! Nothing in software is never truly "done", but as announced previously we are finally at a point where we're ready to retire the X11 and put all our focus on the future. As of today, the Plasma X11 session you can log into has been officially removed, and we will start a mass cleanup of X11-specific code soon. ## When does it take effect? This change will be included in Plasma 6.8, which will be released in around five months. ## What's Changed? In Plasma 6.8, there will be no X11 session in the login screen. There will only be a Wayland session available to log into. In 6.8, all X11-specific code paths in Plasma for Plasma Shell, System Settings, and device configuration will be gone. ## What's stayed the same? XWayland support remains present. You can keep using your X11 applications, and our XWayland application support is second-to-none. If you use KDE applications on another desktop environment, this change will have no effect. KDE applications will continue to work in X11 for the foreseeable future. Plasma Login Manager will continue to be able to log you into X11 sessions of other desktop environments. ## What's Next? The possibilities this opens up are very exciting. Until now, on the desktop side, we've had to target the lowest common denominator or be stuck trying to maintain two conflicting code paths. It was absolutely the right choice to do a gradual transition and approach things this way, but that approach has its limits. Moving forward with a single code path going through Wayland is going to allow us to bring new performance improvements, memory optimisations, and brand new exciting features throughout Plasma. ## How Ready Are We? Our internal metrics within KDE show that over 95% of users of Plasma 6.6 are on Wayland, with a gradual increase every release. The metrics also show that basically no one is testing or developing Plasma on X11 anymore. The platform was already, for all intents and purposes, abandoned by KDE contributors. We have every reason to trust this metric data, as it is exactly in-line with what Sentry (our automatic crash reporting tool) reports for newly-encountered crashes shows. For transparency, the one caveat in all of the above is that I've deliberately always focused on people using the latest Plasma release. We do still have a sizable chunk of users on X11 still using Plasma 5.27. Including them, the total Wayland adoption rate is about 76%. But back then, Wayland wasn't the default session type, so it's hardly a surprise those users are still on X11. Things have come a massively long way in the three years since Plasma 5.27 was released. Anyone still using Plasma 5.27 — or any release older than Plasma 6.8 — won't be affected by what we do in Plasma 6.8, and nothing will be applied retroactively. ## Still Have Issues with Wayland on 6.7? Whilst we have had full confidence since Plasma 6.0 that our Wayland session provides the better overall experience, we are aware that things don't behave exactly the same. Not everything works the same especially in specialised areas. We are not expecting a completely seamless transition for everyone. Custom scripts, tools used and even workflows might have to change. But we are aiming to offer a transition where there is still a way to accomplish all your day-to-day tasks. Plasma 6.7 is the last release that will include an X11 session, and it's coming out in just a few days. If you still have issues that force you back to X11 we would love to hear from you. We can't promise to get everything fixed in time for 6.8, but we can promise to listen and be aware. People's remaining pain point are and will be on our radar, so please take this time to communicate them.

LXQt 2.4 has been released as the newest version of this lightweight Qt-based desktop environment, bringing several usability improvements, particularly for Wayland users. One of the key updates is better multi-monitor support in LibFM-Qt and PCManFM-Qt, where desktop item visibility can now be managed independently for each screen. Additionally, session settings are now split between X11 and Wayland, with Wayland-specific options only appearing when the lxqt-wayland-session package is installed.