BedrockOnLinux 2.2.5

Added

• Settings ▸ Versions: see every Minecraft build you have downloaded, and
  remove the ones you are done with
  (#214). Each build
  is downloaded into a folder of its own, which is what makes going back to
  one instant — and what made them pile up, because nothing ever removed one
  and nothing ever said they were still there. Three versions tried out is
  three copies of a 2.5 GB game, and the only way back was rm -rf on a path
  the launcher never showed. The new tab lists every build on disk with what
  it weighs, marks the one in use, the one that lost its package and the one
  installed before the move to the Microsoft Store, and removes any of them on
  request. Nothing you made is in those folders: worlds, settings,
  screenshots, skins and packs belong to the profile, so a build can be
  removed and downloaded again without touching a single world — which the tab
  says in as many words, because "delete this version" reads like something
  else entirely. A finished download now also names what the builds beside it
  are taking up, instead of leaving the total to be discovered on a full disk.
  On the command line: bedrock-on-linux versions --installed lists them and
  bedrock-on-linux versions --remove <build> removes one.

• PLAY says so when nothing is signed in for online play (#240). The
  launcher asks for two Microsoft sign-ins, and only one of them ever asks for
  itself: the account that downloads Minecraft is offered at PLAY, the moment
  it is needed. The account that plays online never was, so its absence
  surfaced only inside the game, as Realms, servers and friends quietly
  missing — with nothing in the launcher having mentioned a sign-in. Pressing
  PLAY without it now warns first, says what offline mode costs, and offers
  the sign-in on the spot; taking it resumes the launch on its own rather than
  asking you to press PLAY again. Offline is still a legitimate way to play,
  so it is a warning and not a refusal: Play offline carries straight on,
  the warning can be turned off from itself, and Settings ▸ Accounts puts it
  back. bedrock-on-linux play prints the same warning rather than launching
  in silence.

Fixed

• Your Xbox friends can see you again while you play
  (#238,
  #243,
  #244). The
  dressing room said "Offline" under your own gamertag, the social tab said
  it too, and no friend could invite you or be joined. It was not the game
  misreading anything: asked straight out, Xbox Live agreed. Minutes after a
  full launch the presence service still answered state: Offline, last seen
  twelve days earlier — nothing had ever told it Minecraft was running. That
  write belongs to the Xbox services layer the engine cannot bring up under
  Wine, so it never happened, and every reader downstream of it was correctly
  reporting an account that really was offline. The launcher now sends the
  heartbeat itself, for exactly as long as the game runs, using the Xbox Live
  token it already holds for Friends and Social; Xbox names the title, so it
  can say only that Minecraft is being played, and by whom. Stopping the game
  takes it down again, and Xbox drops it by itself a few minutes later if the
  launcher is killed, so nothing can be left permanently in-game. It is on by
  default and Settings ▸ Accounts turns it off.

• bedrock-on-linux doctor --network now answers "why can't I join my
  friend's world?" (#243, #244). The reports were unanswerable: the account
  being invisible, the friends list not loading, and the friend simply not
  being in a joinable world all look identical from the outside, and every
  host in the report resolved and handshook perfectly through all three. The
  report now asks Xbox Live directly and prints what it says — how this
  account looks to other people, whether its friends list reads at all, and
  how many of those friends are in a multiplayer session at this moment. None
  of the three fail the report: an account nobody can see is a real problem
  but not a broken host, and an evening with nobody in a world is not a fault
  at all. doctor also gained an offline xbox presence line saying whether
  the next launch will publish anything.

• Downloading Minecraft no longer fails on the downloader's own package
  cache (#241,
  #242). The
  download read back shorter than what had been written to it, gave up, and
  the attempt after it installed nothing at all without saying why — on a disk
  with 75 GiB free in one report and 700 GiB in the other, so the room the
  message ruled out was never the problem. The downloader streams the package
  through a cache file beside the game and reads that cache back through a
  second handle to work out the package layout, and it counted the bytes the
  runtime had accepted rather than the bytes that had reached the file. A
  write is accepted the moment it is queued on a background thread, so a read
  sent to the same pool could overtake it, find the file short and call the
  package corrupt. Retrying could not order those two operations — it only
  bought another go at the same coin toss, and the go that lost it while
  listing the package files rather than while reading its header exited
  reporting success with no game installed. The fix has been carried in this
  repository since #217
  and reached nobody: a patched downloader is published under a revision of
  its own, and the launcher still asked for the unpatched one. It now asks for
  the fixed build, and continuous integration refuses a patch that is not
  named by the pin, so this cannot happen again quietly.

• The launcher no longer forgets which build you play, and downloads
  another one
  (#214,
  #220,
  #247,
  #248).
  The version picker shows a shortened label — 26.44 for build 1.26.44.3 —
  and that label was what got saved as the selection. Nothing could read it
  back: it names no build the installer can find, so setup reported the choice
  as no longer listed and installed the newest build instead. Picking 26.45
  and landing in 26.44 is the same fault seen from the front, and so is a
  launcher that starts every session by downloading something. Playing an
  older version, closing the launcher and opening it again therefore landed
  on the newest one with nothing having said so, and the next PLAY downloaded
  2.5 GB of a game that was never asked for. The selection is now the build itself,
  labels written by earlier releases are still understood, and the picker
  comes back to what you last played.

• A Microsoft sign-in stuck on "Please wait" no longer takes the launcher
  with it
  (#214). The account
  that downloads Minecraft is linked through Microsoft's own page, in a
  webview xodus-cli owns. When that page stops making progress it prints
  nothing and the process never exits — and the launcher waited on it for
  ever, with capture_output holding every line it might have printed until
  an exit that was not coming. What the player saw was worse than the stall:
  PLAY still ran the whole setup, got as far as the download, found no account
  and stopped — three times over in the report — and every later Sign in was
  a button that did nothing at all, because the flag saying a sign-in was in
  flight had no way left to be cleared. The page is not stuck by accident. A
  token exchange that faults hands back a second address to open, and the
  downloader opened it with no headers at all — none of the nine telling
  login.live.com it is talking to Windows' own token broker rather than to
  a browser. Without them Microsoft serves the ordinary consumer interrupt,
  which is the "Please wait" and the greyed OK: a page that never reaches
  the one address the sign-in is waiting to see, so it waits for ever. The
  second leg of the sign-in is opened like the first now
  (third_party/xodus/patches/, on its way upstream), and the launcher ships
  the downloader built with it. The rest of this stands whatever the page
  does: the sign-in is something the launcher holds rather than waits on. Its window can be closed from the
  account menu or from Settings, which signals the whole webview process
  group; PLAY says the window is open instead of starting a download that
  cannot work; a sign-in that has been up a long time says so; and a second
  one is never silently swallowed. Whatever the sign-in prints is streamed as
  it arrives and kept in logs/store-login.log, so a stall that reaches
  nobody's terminal still leaves something to read. The page's own cache and
  storage — never the tokens, which live in the keyring — are cleared before
  each sign-in and pinned inside the launcher's Xodus home, so a flow
  abandoned half-way is not resumed into by the next one, and nothing of it
  lands in ~/.local/share again. Closing the window is reported as the
  ordinary change of mind it is, rather than as a failure of the launcher.

• A download that fails now leaves something to read
  (#242). The same
  install was reported three times over and every line anyone had was the
  launcher's own: the Minecraft download installed no game and printed no
  reason for it. Nothing was ever written down — the launcher kept the last
  forty lines the downloader printed for the error message and dropped the
  rest — and what it kept was mostly not output at all. The downloader draws
  its progress bars by redrawing one line, padded to the width the terminal
  reports, which for the launcher's terminal was none: a single redraw of
  three bars arrived here as 16 MiB of padding around 438 characters of bar.
  The sentence saying what actually went wrong could arrive in the middle of
  one of those frames, written from another thread. Every attempt now goes to
  logs/store-download.log the way a sign-in already goes to
  store-login.log, the frames are recognised and taken out so what is left
  is the message, and a downloader that has already exited is read to the end
  — a panic is written exactly there.

• Closing the launcher while it was busy in the background could end the
  process on a crash instead of an exit. Settings ▸ Versions adds up what
  each installed build weighs, and both changelogs are fetched over the
  network; all three run on threads that belong to the window. Closing it
  while one was still going destroyed that thread mid-run, which Qt answers
  by aborting the process — no data lost, the launcher was on its way out,
  but it left a crash where a clean exit belonged. The work is now let go of
  rather than killed or waited for: the window closes at once, and the thread
  finishes on its own. Waiting would have been the other answer and the wrong
  one, since two of the three are network reads.

• The Microsoft sign-in window no longer dies where the desktop has
  accessibility running
  (#236). Signing in
  to download Minecraft went blank part-way through — reported on Ubuntu with
  KDE, and recognised straight away as something other WebKitGTK windows do on
  Arch and NixOS too — leaving nothing to go on but a WebKitWebProcess
  coredump in the system journal, and a launcher that could only say the
  sign-in had not completed. That page is drawn by a process of its own, and
  WebKitGTK publishes it on the accessibility bus; its AT-SPI text interface
  then maps an attribute run back onto UTF-8 offsets by indexing a table with
  the end of that run, which the code above it allows to point past the end of
  the text it belongs to. A single GetAttributeRun landing on such a run
  reads off the end of the array and aborts the process on the spot, taking
  the sign-in with it. Nobody asks for that: the caller is whichever
  accessibility client happens to walk the window, and the fault is still
  present in WebKit's own tree, so there is no version to update to. The
  launcher now keeps that window off the accessibility bus, the same way it
  already keeps it off the DMABUF renderer, and for every xodus-cli call
  rather than the sign-in alone. Nothing else about the window changes — it is
  simply no longer readable by assistive technology, which is a real loss
  where it is needed: BOL_WEBVIEW_A11Y=1 asks for the bridge back, a
  WEBKIT_A11Y_BUS_ADDRESS you set yourself still wins, and the game is never
  started with either.

Build provenance

Application artifacts built from source, consuming this
fork's attested, pinned engine and OpenSSL-XCurl set.

Bill of materials (pinned + reproducible):

• Managed engine: wow64-archs-native17 (sha256 12fa379f012410832eab54c719efaa4e0e327a3b6839b0859f851d1b952abed2)
• WineGDK source: 75637b674e1f191e65753663c4c0c32bea05ba6e (prefix sha256 bfbb08107e7aa16842cf12814013a1cb94acd5a1c2fe8eaec24a401c4b57fc09)
• vkd3d-proton: 3.0.1-nv-dgc (output-hashes sha256 09d22ca93ae4b0a2f99294a43cec6a89a2bd92b96dffb14f2fcc5cf66685b3df)
• OpenSSL-XCurl set: 504bb166e4e7

Verify any file with:

gh attestation verify <file> --repo Wyze3306/BedrockOnLinux

What's Changed

• feat(readme): add nix/nixos into readme by @Mih4n in #246

New Contributors

• @Mih4n made their first contribution in #246

Full Changelog: v2.2.4...v2.2.5