1.0.4

Docker stops being the second-class way to run a version, and the manager starts
behaving like an application: closing its window closes everything it started.

The Docker edition, visible in the manager

A version running in a container used to leave no trace on the shelf. The row
said "not installed" over a gigabyte of built image, and showed nothing at all
over a browser that was open — because the job that starts a container exits as
soon as the desktop answers, so there was no job left to look at.

The cause was a mismatch worth naming: a container always runs the Linux
x86_64 build, and the shelf was comparing its revision against the one this
host installs natively. For Chromium 60 that is 474900 against 474901, so
"Stop Docker container" never once appeared.

Now, per row:

• the running dot and the Running filter count containers, not just native windows;
• a green Docker marker shows the image size, or Docker · running when the
  container is up — and then it is a link back to the desktop tab, which was easy
  to close and impossible to find again;
• the primary button is Stop while the container runs, and Launch when the
  image is built but idle: one click, no download;
• the row menu offers Open the desktop, Stop the container, Launch
  natively as well, and Delete Docker image, with the size on the label —
  reclaiming that gigabyte previously meant raw docker commands;
• the sidebar Disk read-out has a Docker line, and the header total includes
  it. On a machine with two images built, the old gauge was under-reporting by
  more than 2 GB.

Docker actions are only offered for milestones that actually have a Linux build
to put in a container. Before, the manager offered it for every row and let the
launcher fail with the reason buried in a job log.

Copy and paste in the container's desktop

noVNC ships a clipboard side panel and nothing else: the canvas swallows every
keystroke, so text copied anywhere else on the machine could only get in by being
pasted into that panel by hand.

Both directions work now. Your usual shortcut pastes into the container, and
anything copied inside it lands on your own clipboard. On a Mac that means
Cmd-C, Cmd-V and Cmd-X — which the Linux desktop in there would otherwise
never see, since noVNC forwards Cmd as Super and no application answers Super-V.

The manager closes like an application

It used to be a tab you closed and a server you forgot about, still holding a
port and still parenting every browser it had launched.

• The manager opens in a window of its own — a Chromium-family browser in
  --app mode with its own profile, which is what makes closing it unambiguous
  and keeps the manager out of your browsing session. Without such a browser it
  falls back to a tab.
• Closing the window quits everything: the server stops, the browsers it
  launched close, and the containers it started come down. Ctrl-C in a terminal
  does the same.
• If any of that is still running, the browser asks you to confirm first, so a
  stray click on the X cannot take a download with it. Idle, the window closes
  without a word.
• A download interrupted by the shutdown is cleared up rather than left as an
  80 MB orphan that can never be resumed. Only for versions this manager was
  working on — a second manager against the same directory keeps its own.
• Suspending the machine is not a closed window. Shutting a laptop lid used to be
  indistinguishable from closing the manager, given a heartbeat that had simply
  stopped arriving.

New flags on gui.sh / gui.ps1: --tab for a tab in your default browser,
--keep-alive to leave the server running whatever the window does, and
--no-open (which implies --keep-alive) for a bare server.

Fixed

• Two versions in Docker at once. Both starts saw port 6080 free, and the one
  that lost the race reported "Could not start the container". A refused binding
  now moves up a port and tries again.
• A version that could never start again. stop removed its container
  outright, so the browser inside never got to release the lock in its profile
  volume. The next start then failed with "the profile appears to be in use by
  another Chromium process on another computer" — permanently, for that version,
  after one hard stop or one crash. Containers are now stopped with SIGTERM first,
  the entrypoint passes it on to Chromium, and a lock left behind by a container
  that is already gone is cleared at startup.
• Chromium 60 in Docker died on startup, exit 127: the oldest milestones link
  against libgconf-2.so.4, which Debian dropped after buster. The image now
  fetches it from the Debian archive — so the milestones Rosetta is least
  reliable with are the ones the container can now actually run.
• The container's log named Chromium 74 whatever revision it was actually
  running.

Changed

• The container's desktop is published on 127.0.0.1 only. It has no password
  and a real browser attached to it, and a plain -p put it in front of everyone
  on the network.
• ~/.chromium-stack/manager-window/ appears: the browser profile behind the
  manager's own window, a few tens of MB of browser plumbing. Safe to delete when
  the manager is closed.

Upgrading

Rebuild any Docker images you already have. The clipboard bridge and the
libgconf fix are baked into the image, so an image built by an earlier version
has neither:

./chromium-stack-docker.sh rebuild 74

Everything else is scripts and the page — extracting over the old copy is enough.