Files
orca/mobile/web-entry
Jinwoo Hong 0ab2ba3480 fix(mobile): the page stops writing, importing and requesting what it cannot use (#22241)
* fix(mobile): the page keeps no host app-version record

`host-status-gates.ts` runs above every page route, and a readable
`status.get` had it write `orca:host-app-version:v1:<hostId>` through
`host-app-version-store.ts`. Inside the page AsyncStorage is the bridge's
adapter and that key is not one `page-storage-keys.ts` hands a route, so
every mount posted a write the shell refused and logged as
`storage-write-dropped`.

Not admitted through the storage seam, because the page never reads it
back: the record's only reader is the native troubleshoot screen's
`native-diagnostics-operations.ts`, which is not in the page's bundle. A
`.web` sibling keeps no record instead. The bounds check moves to
`host-app-version.ts` so both hosts read a reported version the same way.

The session render check now collects warnings as well as errors and
answers `status.get`, which is what arms the write: the other cases'
double answers no RPC, so the drop needed a reply rather than a control.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb

* fix(mobile): the page does not import expo-notifications

`DevicePushTokenAutoRegistration.fx` runs at import: it adds a push-token
listener React Native Web answers with a warning, and it reads the
persisted server registration out of `window.localStorage` behind a
`typeof localStorage === 'undefined'` guard. The Android shell's WebView
has DOM storage off, where `window.localStorage` is `null` rather than
undefined, so the guard passed and the read raised "Cannot read
properties of null (reading 'getItem')" at error level on every page
load.

Two modules imported the package — `push-token.ts` and
`desktop-notification-channel.ts`, both reached through
`push-registration.ts`, which the host layout pulls in via the host
screen's remove action. Both get a `.web` sibling. The page holds no
device push token and creates no Android channel; push registration
needs a token the shell owns and a gateway the page has no client for.

Every call in those two files was already inert on web, so a page that
imports one behaves correctly and still loads the package: the closure
check beside them is what keeps a third importer out. The session render
check adds the device's own shape — `localStorage` reading `null` — and
reds on the error the emulator saw.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb

* fix(mobile): the page declares an icon, so no browser asks for one

With none declared a browser asks the origin for /favicon.ico on its
own, and the shell's asset server answers 403 because the path is in no
manifest — which the emulator run saw repeatedly. The document now
carries `<link rel="icon" href="data:," />`, a browser's own way of
being told there is no icon. An empty data URI rather than an asset: the
page is a WebView document with no tab to put an icon in, and the
bundle's images are content-hashed route assets whose names change with
their bytes. `img-src 'self' data: https:` already admits the scheme.

Two assertions, because each is blind where the other sees. The build
check reads the document and runs everywhere. The session render check
reads the request, which only a full Chrome makes —
`ORCA_MOBILE_WEB_RENDER_BROWSER`, what CI resolves — and reads it off the
server's own log: a favicon fetch comes from the browser process rather
than the page, so Playwright's request events never report one. It also
settles on network idle first, because the fetch comes after the text the
route waited on.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb

* docs(mobile): trim the page-noise comments to the bar

Comment-only. The three `.web` siblings, the document's icon line and
the three override reasons each said their cause once and then said it
again; each now states what the page keeps and why, once.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb

* test(mobile): re-pin the session closure after expo-notifications left

Measured on this head with all five generators run first, against a
scratch worktree detached at the base, which reads the committed pin
exactly: 4271 modules and 1023 local.

    modules        4271 -> 4210   (-61)
    local modules  1023 -> 1024   (+1)

65 modules leave and 4 join. 62 of the 65 are vendored: expo-notifications'
own 55, and expo-application, badgin, abort-controller and event-target-shim
behind them. The other three are the native files the `.web` siblings
replace, so the siblings cost the local count nothing and its +1 is
`host-app-version.ts`, the one new module.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb

* docs(mobile): count the packages the closure note names

The note said 62 vendored modules left and then named five packages
without counts, so the names read as the whole of the 62 and summed to
five. Each carries its own count now: 55 + 3 + 2 + 1 + 1.

Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb
2026-09-22 08:07:16 -04:00
..