Files
NotAlexNoyleandClaude Fable 5.1 62af6e82c7 The engine on UXP RB_20261027 (T-551..T-554): the queue rebased, 0060 dropped, every pin, the device checked
The owner's choice of 2026-11-02 after T-551's check found the tag: the update now, patch 0060 (the
roots, byte-identical upstream) dropped, special attention to the certificate and HTTPS changes.
- update-engine.sh RB_20261027 / --finish: the 72 patches on the tag (0060 fell away as already
  applied), jihad/uxp-RB_20261027 at 52ad9ab66e in third_party/uxp, the queue rewritten and
  renumbered from 0060, the pins (engine-version.env, the OE recipe, .gitmodules, the UA and the
  three start pages: UXP/6b18be9), JIHAD_APP_BUILD_ID 20261103000000; patch-queue.sh --check,
  check-engine-pins.sh and check-engine-api.py (baseline rewritten, unchanged) agree.
- docs/ENGINE-SOURCE.md: the base, the dropped 0060, the renumbering, and the range's 12 commits
  each with its disposition — the two NSS certificate commits (emSign removed after the eMudhra
  compromise; certdata to Sept 2026) were on the device since the roots of 2026-10-25 and are the
  base's now; no PSM, TLS protocol, HSTS or certificate-UI change in the range; the memory-safety
  fixes (the JS OOB array copy, the jar: flag, feTile, the layout frame table, the mutation
  observer's strong ref, SQLite 3.54.1) taken with the base.
- audit-roots.py against the fetched release certdata and the CCADB report: identical set and
  trust, none removed, RESULT OK (docs/rounds/certs-2026-11-03).
- Desktop: the full build clean; 14 of 18 tests pass, the four left are the desktop GTK path's
  known read-back limit. ARM: libxul, the daemon, the bundle, the three packages; full pushes to
  all three variants; default-check x3 faults 0; the daemon's start line 28 of 29 optional
  exports as before. The areas the commits touch, on the device (tools/device/engine-checks.sh,
  new): about:settings, about:personas and about:addons through jar: under the flag change,
  cookies through the new SQLite, an SVG filter page with feTile and its overflow case
  (render/goanna/test/jihad-svg-filter.html, new), a long press's selection; faults 0.
  The certificate kit's checks (tools/device/cert-checks.sh): the TLS 1.0 refusal, the clean loads,
  expired / wrong.host / self-signed / untrusted-root with the SSL confirm's right flags, OCSP
  revocation enforced on grc.com, ssl.com and DigiCert's demos, revoked.badssl.com's CRL-only case
  invisible as before: nothing changed with the base.
  Records: docs/rounds/engine-rb27-2026-11-03/notes.txt.
- tools/device/cert-checks.sh and t502/enyo-restore-job.sh (new): the certificate kit's device
  checks under a hand-started daemon, and the Enyo job put back after any spike round.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-11-03 10:25:46 -05:00
..

app-mochi — Mochi (Enyo 2) UI variant

A second Jihad Browser front-end, built on Enyo 2 + the Mochi UI library (LG's touch-focused, never-officially-released Enyo 2 widget set; Apache-2.0). It is functionally equivalent to the legacy Enyo-1.0 UI in ../app, and uses Mochi controls (Input, InputDecorator, ProgressBar, ToggleButton, …) over a Fittable layout.

mochi.Popup is UNUSABLE here — a floating/modal Popup crashes the app card on this engine (device, 2026-07-20). Every menu and dialog is a plain enyo.Control overlay (a scrim + a box toggled by showing). Likewise the engine renders no mochi sprite icons, CSS-background SVGs, CSS circles, or the needed font glyphs, so toolbar icons are PNG data URIs. Do not "modernise" these back — see PARITY.md and ../context/impl/impl-mochi.md.

This ships as a separate .ipk (net.riverstonerelay.jihad-browser-mochi) so it coexists with the Enyo and Mojo variants on the device — three browsers, installed and running side by side. Each drives its own BrowserServer instance through the unchanged BrowserAdapter contract.

Status: live on the device. The card runs on hardware bound to its own MIME, drives its own daemon over its own socket, and loads pages end to end; <select> dropdowns and the start page are device-verified. source/ implements the shell (NPAPI-bound JihadWebView, toolbar, load progress, app-chrome start page) plus the parity views — bookmarks, history, downloads, find-in-page, preferences — and the engine-driven dialog set (alert / confirm / prompt / auth / SSL). What is still unverified on hardware is the long tail of those parity views (live db8 and download-manager round-trips, dialog presentation); feature-by-feature status, including every intentional omission, is in PARITY.md, and requirements are in ../context/kits/cavekit-mochi-ui.md.

Why two UIs

  • ../app — the proven isis Enyo-1.0 UI (lowest risk; what isis-browser ships).
  • app-mochi — a modern Enyo-2/Mochi UI (nicer touch UX), the same browser underneath.

Framework stack (bundled at build time, not vendored here)

  • Enyo 2.x core (enyo/) — from the enyo 2 framework.
  • layout library (lib/layout/) — FittableRows/Columns, Panels, List.
  • Mochi (lib/mochi/) — from ../../mochi (Apache-2.0, LG).

Packaging

build/webos-oe/build-mochi-ipk.sh builds the .ipk. It stages this directory (appinfo.json, index.html, icons, source/) together with the three external framework trees above into a layout matching index.html's <script src> paths, then runs palm-package. The frameworks are pulled from outside the repo at build time (never committed); the staging tree and the .ipk land under build/webos-oe/out-mochi/ (git-ignored). Source roots are overridable via ENYO_SRC / LAYOUT_SRC / MOCHI_SRC; the layout library is resolved from the first candidate that actually contains package.js.

The app id is net.riverstonerelay.jihad-browser-mochi — distinct from the Enyo variant (net.riverstonerelay.jihad-browser), so both .ipks install and coexist. The suffix is a hyphen, not a dot, and that is load-bearing: ipkg stores package metadata as info/<pkgid>.{control,list,prerm} and removes a package by globbing <pkgid>.*, which also matches <pkgid>.mochi.control. With the old dotted id, removing the Enyo package destroyed this package's control scripts and file list, leaving it un-uninstallable (../context/impl/impl-ipkg-prefix-collision.md). The launcher title is "Jihad Mochi" (and "Jihad Enyo" / "Jihad Mojo" for the siblings): the earlier directive gave all variants the identical title "Jihad Browser", which stopped being usable once all three shipped and ran side by side, so the launcher now distinguishes them while the in-app branding stays unified — every start page says "Jihad Browser" over the shared logo. Icons are the shared Jihad Browser set (identical bytes to ../app/icon*.png).

This package owns its own db8 kinds. Bookmarks/history/preferences use net.riverstonerelay.jihad-browser-mochi.{bookmarks,history,preferences}:1, declared in db/{kinds,permissions}/ HERE, owned by this app id, and registered by the appinstaller out of this .ipk. Nothing is shared with the Enyo variant.

Until review F-1 they were the ENYO variant's kinds, shipped only in that package with a permission grant extended to this app id — so installing Mochi alone registered no kinds at all and every db8 call failed, and removing the Enyo package destroyed this variant's data. That is the co-ownership cavekit-device-build.md R7 forbids. A db8 kind's owner must equal the app id that registers it, so independence means a separate namespace, not a broader grant; there are deliberately no cross-variant permissions. The consequence is by design: history and bookmarks are per variant — this browser does not see the Enyo browser's history, exactly as it does not share its engine profile.

After a dev palm-install (which does not run the appinstaller's kind registration) run build/webos-oe/register-db-kinds.sh mochi once.

Contract invariant

The Mochi UI uses the identical callBrowserAdapter(...) method set and palm://com.palm.browserServer/* URIs as ../app. The new UI-side piece is source/JihadWebView.js — an Enyo-2 WebView-equivalent control that renders the BrowserAdapter NPAPI <object> with this variant's own self-contained MIME application/x-jihad-browser-mochi (the Enyo variant keeps application/x-jihad-browser; see ../context/plans/plan-variant-identity.md) and exposes the same adapter method surface (see cavekit-mochi-ui.md R3). See ../docs/IPC-CONTRACT.md.

UI notes learned on device

  • mochi.Popup is unusable on this engine — a floating/modal Popup crashes the card. Every overlay here (overflow menu, dialogs, the <select> list) is a plain Control toggled by showing over a scrim. This is a hard constraint, not a style preference.
  • The card WebKit (~534.x) ignores unprefixed box-sizing and modern flexbox. source/JihadBrowser.css must use -webkit-box-sizing and the -webkit-box flexbox syntax; an unprefixed declaration is dropped silently and a width:100% row with padding then overflows the card (that bug cost real time on the sibling Mojo variant — its toolbar measured 784 px on a 768 px screen).
  • <select> dropdowns are handled here, unlike in the Enyo variant where the framework wrapper does it: JihadWebView.showPopupMenu surfaces the adapter callback as onOpenSelect, and JihadBrowser renders the list, anchors it under the tapped control from the rect the daemon ships, and replies with the chosen index — or -1 on dismissal and on any payload it cannot present, so the daemon always releases the element it is holding.

Iterating on this UI

../build/webos-oe/push-card-js.sh mochi source/JihadBrowser.js … pushes card files to a connected device and reports success only once a per-push stamp reaches the device log; the WebAppMgr JS cache will otherwise keep running the previous build with the new file already on disk. See ../build/webos-oe/README.md.