[christianhg]

The Android IME driver from #3511 lives in apps/android-ime together with the editor's device tests, so nothing outside that app can type on real Gboard. This PR moves the driver into a private workspace package, thumbjar, and makes the editor's device tests its first consumer.

thumbjar exports typeOnDevice, thumbjar/page exports recordInput for the test page, and thumbjar/vitest exports deviceProject. The thumbjar command fetches the uiautomator2 jar, serves the page and prepares the device. The device tests, their page and run-on-device.sh move to packages/editor/android, with their own Vitest config rooted there. The workflow runs from packages/editor, and apps/android-ime is deleted. The fake-typing suite still runs in root pnpm test:unit through the editor's test:unit.

thumbjar builds to dist with pkg-utils like racejar, with source and default export conditions, so turbo's ^build builds it before the editor's tests. Raw .ts exports made the editor's test:unit fail at config load on Node below 22.18, which the editor still supports. The thumbjar bin is a checked-in shim that imports dist/bin.js, because pnpm links a bin only when its file exists at install time. Root check:knip runs Knip with the source condition, since it loads the Android Vitest config straight after install.

Two driver changes come with the move. The page URL is now built with URL and searchParams instead of string concatenation, and openInChrome shell-quotes the remote am start command, because adb joins its arguments into one device shell command and a & in the URL split it. A test runs that command through /bin/sh and asserts the exact arguments am receives. It fails on the unquoted code.

The move comes first as its own commit, with every file renamed unchanged, so git log --follow reaches the app's history. The formatting those files skipped under the app's ignored lib/ follows in the next commit. thumbjar now runs under the stricter oxlint rules for packages/, and the shared runSuite helper is exported once from thumbjar/testing instead of copied into the editor. The editor's published file list is unchanged.

Before the later commits, five measured runs of the device workflow on 401d5cc had all 10 jobs green on the first attempt. One of 30 cases was retried once after Chrome DevTools dropped its connection, and then passed. Job times were 4.1 to 5.7 minutes, against about 5 to 8 on the #3511 baseline.

This PR also carries the work that was stacked on it, in commit order. Each part below was reviewed as its own PR before it was folded in.

Type into textarea and text input fields

thumbjar's driver could only type into a [contenteditable]. It found its field with document.querySelector('[contenteditable]'), and recordInput read textContent, so a textarea or text input was either missed or recorded with empty or stale text. That rules out a plain textarea as a control page and any app whose field is not a contenteditable.

A page now names its field through the existing field option of recordInput, and the driver asks the page for it through window.__field(). Without a named field the driver takes the first textarea, text input (no type, text, search, tel, url or password) or [contenteditable]. Other input types are skipped because they hold no text or reject setSelectionRange. A field's text is its value for a textarea or input and its textContent otherwise. The forced focus puts the caret after the value with setSelectionRange and keeps the range collapse for a contenteditable. The focus check now accepts only the field or an element inside it, not any focused contenteditable. On the two shipped pages, which have one contenteditable and no other field, the driver taps, measures, focuses and reports exactly what it did before, including every answer of the focus polling.

When Chrome has fallen out of the foreground and the driver reopens the page, it now runs the same readiness check as on the first load before it looks up the field. Without it, a page that names a field could get the first matching field instead, because the new document had not run recordInput yet. When the page is already ready this adds the readiness reads and nothing else. A navigation that commits after that check passed on the old document can still outrun it, because cdpEval attaches to the first page target with the URL and has no notion of which document it is. The section on late fields below covers what the driver now does about that.

The docs now say a page seeds its field and leaves it to the keyboard. A textarea whose value was written back from page state on each input nested 7 of 8 Japanese compositions on real Gboard.

The second commit adds textarea.html, a plain textarea control page, and tests/en-textarea.test.ts, which types kyou twice on English Gboard and expects Kyou kyou . It lives in its own file because tests/en.test.ts already holds the three tests a device file may declare, and run-on-device.sh only runs tests/$IME_LANG.test.ts, so CI does not run it. It has not run on a device yet.

The unit tests run the real typeInChrome against a mocked CDP and a jsdom page and pin the named-field reopen, the absent-hook fallback, the 20-attempt readiness bound, the skipped input types and the narrower focus check. Each fails on the code before the change.

Cases as step lists with runOnDevice

typeOnDevice can only type words and commit each one, so a case can't press Enter while a word is composing or Backspace at the start of a block. runOnDevice takes a case as a list of steps instead:

test('enter while composing', async (context) => {
  const records = await runOnDevice(context, {
    url,
    keyboard: 'ja',
    prefix: 'ja-enter',
    steps: [
      {type: 'compose', letters: 'kyou', commit: 'none'},
      {type: 'enter'},
      {type: 'backspace', times: 2},
    ],
  })
})

Every step is checked against what the driver can do on the keyboard before the device is touched. A step it can't drive skips the test through context.skip, and the skip note names each such step by position and reason. Otherwise the call returns one record per step with its status, the text and selection after it, and the events between the step's two boundaries. A boundary reads the page state and the field's selection in one evaluation, so every event lands in exactly one record. A step that throws is a driver fault, so the whole case is retried once like typeOnDevice, and a page exception is never retried. When the last attempt fails, the test fails with an error that lists that attempt's step records, with the thrown value as cause.

Everything that belongs to the test (the skip, the timeout signal, the artifact names and the driverRuns record) comes from the context Vitest passes to the test, not from getCurrentTest(). The current-test pointer can name a concurrent sibling, or the next test when a timed-out test's body resumes late, and skipping through it would hide that test's failure. Concurrent tests may call runOnDevice. A late call after a timeout records an aborted run against its own test and rejects without touching the device. The context check only looks at the shape, so passing another test's context makes that test the owner.

There is one behaviour change in the shipped typeOnDevice. Simultaneous calls of either entry now run one after another. Before, two calls that arrived together both awaited the same previous run and drove the device at the same time. A queued call spends its own test's timeout while it waits. Sequential calls behave as before. For plain Word lists, typeOnDevice taps, records and writes byte-identical artifacts across the unit suites, compared case by case against the base branch. The commit message lists the two exotic-input differences (a throwing candidate getter is read earlier, and a non-iterable letters throws with different TypeError wording).

Diagnostics on the runOnDevice path never replace the original failure. That includes a thrown value whose message throws or is a Symbol, a revoked Proxy, a failure artifact that can't be serialized, and an abort reason that can't be printed. typeOnDevice keeps its plain diagnostics. Two limits stay: a replaced console that throws while logging the warning for an unwritable artifact, and a getter that never returns. In-process guards can't contain either.

Each fix is pinned by a unit test that fails on the code before it. This has not run on a device yet.

One CI job per device test file

The Android IME workflow ran one job per language, so a device test file could only run in CI by being named after a language, and every file ran under thumbjar's fixed three-test cap. When an emulator died after boot, as hosted emulators sometimes do, the job went red with nothing to tell the infrastructure failure apart from an editor bug.

The matrix now has one row per device test file (tests/ja.test.ts and tests/en.test.ts), and each file runs under a cap derived from how many tests it holds. thumbjar's deviceTestFileSeconds(testCount) replaces the fixed constants. scripts/budget.test.ts fails when the workflow's timeout-minutes no longer match the caps, when the matrix doesn't list exactly those files, or when a file's counted tests differ from what Vitest collects. tests/en-textarea.test.ts stays a hand-run control.

A failed run is retried once on a fresh emulator only when adb proves the device was lost. After a failed prep or test stage, the script reads adb get-state once, under its own 5-second timeout, and records a single verdict line before logging anything. offline, error: device offline and "no such device" count as lost. Those are the answers dead emulators gave in earlier runs, and the tests use them as fixtures. Anything else is not proof: an unauthorized or bootloader device is still there, and a hung adb may only be slow. A failure on a reachable device is never retried, because a retry could turn a real failure green. A booted run that ended without a completed check, for example by its step timeout, is reported as "the run ended after boot without a completed device check, not a test result" and is not retried either, because the emulator is already gone by the time a later step could look. The old never-booted retry stays, and a retry is never retried.

The scripts are covered by unit tests with a fake adb, including runs of the real run-on-device.sh. None of this has run on a hosted emulator yet.

Device prep: Play Store block and the Japanese dictionary

Two things made a hosted-emulator device run fail for reasons that had nothing to do with the editor. From about 150 seconds after boot, Play Store updated Play services, Chrome, WebView and Gboard on its own, and installing Play services killed Chrome mid-test. And the Japanese prep handed the device to the tests while Gboard could still be running its minimal Mozc engine. A session created before the dictionary loads never converts, so kyou offered only きょう and a test that commits 今日 failed on the device, not on the page. Neither failure said what it was.

thumbjar prepare now disables Play Store before the tests. The step has its own cap, logs one self-update block: line and never fails the prep. Gboard downloads its dictionary itself, not through Play Store, so the block does not hold the dictionary back.

For --keyboard ja the prep captures the device log from the start, then waits for Gboard's New data is loaded line for its mozcdata-*.data file, at most 360 seconds after the run script saw the emulator come online (--booted). Once it has loaded, the prep switches Gboard away from Japanese and back, requires a RELOADED line after that switch, types kyou and requires a kanji candidate. The check reuses the driver's own openKeyboard, ensureJapanese, dismissAnr and gboardKeys, so it gets the same ANR dismissal, Chrome foreground recovery, Space swipe and romaji QWERTY check as the tests. The only change in typing.ts is the export on those four functions. A dictionary that never loaded fails the prep with a line that says so first, then names Gboard's version, its fallback engine and cancelled downloads.

The 360-second deadline is on the host clock and the log lines are on the device clock. The wait converts once, from one whole-second device reading taken between two host readings, and takes the latest cutoff that reading allows. So a load inside 360 seconds always counts, and a load at most the adb round trip plus 1 second late can count too. A load later than that fails even when the wait first reads it after the deadline, which is stricter than the harness this was ported from. The log reader runs in its own process group, and every exit path (pass, fail, deadline, SIGTERM) stops it and reaps it, pinned by tests with a fake reader that ignores SIGTERM.

On the CI side, each row now carries its own keyboard's caps: 632 seconds of prep for English (the old 600 plus the Play Store block, nothing else changes) and 889 for Japanese. Every run step gets 60 seconds of named headroom for the action, shell and pnpm startup that no internal cap counts, so the step cannot end before the script logs its own reason. The run steps come to 53 and 57 minutes and the jobs to 155 and 163. A failed prep's reason goes into the job summary, and a prep failure on a reachable device is still never retried.

Everything is covered by unit tests with a fake adb, including runs of the real prepare.sh and run-on-device.sh. The dictionary check has not run on a hosted emulator yet. The first CI run is its first real test.

Wait for a field that renders late

recordInput documents that a page that names no field may render the field after it runs, but the driver only waited for window.__state. A page that had run recordInput without its field yet passed the readiness check, and the tap rect then read field.style on null. That is a page exception, which is never retried, so a slow render failed the test as if the page were broken. The readiness check in waitForPage now also waits for the field, within the same 20 checks a second apart. A field that never renders fails with page never rendered its field, a driver fault, so the attempt is retried. A page that never loads or never runs recordInput still fails with page never loaded over CDP.

That check is its own evaluation, and cdpEval picks the page target by URL afresh for each expression, so a navigation or a re-render after it could still hand the tap rect or the forced focus a document without a field. FIELD_RECT and FOCUS_FIELD now look the field up and return null without one in the same evaluation, and the driver evaluates each again a second later, up to 20 times, before it throws the same driver fault. An exception the page throws in either still fails the attempt at once. A document that replaces the page and has not run recordInput by the time the driver reads window.__state() still raises a page exception, whether it commits before or after the focus. The README says so. The tests run the real typeInChrome against a mocked CDP and a jsdom page, and each fails on the code before the change.

Stop deleting Chrome's saved tabs

The cleanup after each test, and after the Japanese prep's dictionary check, ran rm -rf on Chrome's app_tabs directory. The CI emulator image runs adb as a non-root shell user, so the command failed with Permission denied on every job and the driver logged it and went on. The step never cleared anything, so it is removed, and the cleanup only stops Chrome. The tests in each device test file open distinct URLs, and the driver matches the page target by its exact URL, so a tab Chrome restores from another test does not match.

The cleanup bound drops from 35 to 20 seconds, and the budgets derived from it drop with it: a typeOnDevice call from 535 to 520 seconds, the device test timeout from 575 to 545, and a file of three tests from 1825 to 1735. The workflow follows, with run steps of 52 and 56 minutes and jobs of 153 and 161 for English and Japanese.

One case this does not cover: the Japanese prep's dictionary check opens editor.html?prefix=, the same URL as the second Japanese test, so a tab restored from the prep could match that test's page. This is not new, because the removed step never succeeded on CI, and it is left for a follow-up.

---

Note

Medium Risk
Changes Android CI orchestration and the shared device-typing harness used to guard editor input/composition behavior; production npm files stay editor-only, but mis-tuned retries or budgets could hide or flake real regressions.

Overview
Removes apps/android-ime and colocates Android Gboard emulator device tests under packages/editor/android, with the typing driver, device prep, and Vitest hooks extracted into a new workspace package thumbjar (typeOnDevice, recordInput, prepare/serve CLI, deviceProject).

Test pages and specs now call thumbjar (keyboard + full url instead of lang/page), and CI builds via @portabletext/editor build:android and thumbjar fetch-u2-jar. Path filters and docs point at packages/editor/android and packages/thumbjar.

The Android IME workflow is reworked: the matrix is one job per device test file (ja.test.ts / en.test.ts) with per-row run_minutes / job_minutes from budget.mjs (aligned by budget.test.ts). Retries use emulator-runs.mjs for boot failures and adb “device lost” after boot, with adb get-state verdicts in timing.txt so infra failures are separated from test/prep failures. run-on-device.sh takes a single test file, runs thumbjar prepare, and records richer result lines for the job summary.

Supporting updates: vitest.android.config.ts, knip entries for editor android + thumbjar, root check:knip with the source condition, and a hand-run en-textarea.test.ts control (not in the CI matrix).

^{Reviewed by Cursor Bugbot for commit fbf00ea. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
portable-text-editor-documentation	Ready	Preview	Nov 4, 2026 2:23pm UTC
portable-text-example-basic	Ready	Preview	Nov 4, 2026 2:23pm UTC
portable-text-playground	Ready	Preview	Nov 4, 2026 2:23pm UTC

[changeset-bot]

⚠️ No Changeset found

Latest commit: fbf00ea

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Bundle Stats

✅ No significant changes.

All scenario measurements (37)

🗺️ @portabletext/block-tools / @portabletext/block-tools · @portabletext/block-tools / @portabletext/block-tools/rules · @portabletext/editor / @portabletext/editor · @portabletext/editor / @portabletext/editor/behaviors · @portabletext/editor / @portabletext/editor/plugins · @portabletext/editor / @portabletext/editor/selectors · @portabletext/editor / @portabletext/editor/traversal · @portabletext/editor / @portabletext/editor/utils · @portabletext/editor / defineSchema · @portabletext/editor / useEditor · @portabletext/editor / typical · @portabletext/html / @portabletext/html · @portabletext/html / @portabletext/html/rules · @portabletext/html / htmlToPortableText · @portabletext/keyboard-shortcuts / @portabletext/keyboard-shortcuts · @portabletext/markdown / @portabletext/markdown · @portabletext/markdown / portableTextToMarkdown · @portabletext/patches / @portabletext/patches · @portabletext/repair / @portabletext/repair · @portabletext/sanity-bridge / @portabletext/sanity-bridge · @portabletext/schema / @portabletext/schema · @portabletext/plugin-character-pair-decorator / @portabletext/plugin-character-pair-decorator · @portabletext/plugin-decorations / @portabletext/plugin-decorations · @portabletext/plugin-dnd / @portabletext/plugin-dnd · @portabletext/plugin-emoji-picker / @portabletext/plugin-emoji-picker · @portabletext/plugin-input-rule / @portabletext/plugin-input-rule · @portabletext/plugin-list-index / @portabletext/plugin-list-index · @portabletext/plugin-markdown-shortcuts / @portabletext/plugin-markdown-shortcuts · @portabletext/plugin-one-line / @portabletext/plugin-one-line · @portabletext/plugin-paste-link / @portabletext/plugin-paste-link · @portabletext/plugin-sdk-value / @portabletext/plugin-sdk-value · @portabletext/plugin-typeahead-picker / @portabletext/plugin-typeahead-picker · @portabletext/plugin-typography / @portabletext/plugin-typography · @portabletext/toolbar / @portabletext/toolbar · @portabletext/toolbar / typical · @portabletext/plugin-table / @portabletext/plugin-table · @portabletext/plugin-table / @portabletext/plugin-table/ui · Artifacts

Scenario	Kind	Bundle (raw / gzip)	Gzip change	Import time	Import change
⚪ @portabletext/block-tools / @portabletext/block-tools	export	338.3 KB / 40.0 KB	None	95 ms	-0 ms, -0.4%
⚪ @portabletext/block-tools / @portabletext/block-tools/rules	export	15.2 KB / 2.1 KB	None	3 ms	-0 ms, -0.3%
⚪ @portabletext/editor / @portabletext/editor	export	1.02 MB / 130.3 KB	None	42 ms	+0 ms, +0.9%
⚪ @portabletext/editor / @portabletext/editor/behaviors	export	4.3 KB / 147 B	None	1 ms	-0 ms, -2.1%
⚪ @portabletext/editor / @portabletext/editor/plugins	export	5.1 KB / 645 B	None	4 ms	-0 ms, -1.3%
⚪ @portabletext/editor / @portabletext/editor/selectors	export	96.3 KB / 9.4 KB	None	4 ms	-0 ms, -3.7%
⚪ @portabletext/editor / @portabletext/editor/traversal	export	46.6 KB / 4.2 KB	None	3 ms	+0 ms, +1.3%
⚪ @portabletext/editor / @portabletext/editor/utils	export	32.8 KB / 4.1 KB	None	3 ms	+0 ms, +0.5%
⚪ @portabletext/editor / defineSchema	consumer	658 B / 69 B	None	None	None
⚪ @portabletext/editor / typical	consumer	1.02 MB / 130.0 KB	None	None	None
⚪ @portabletext/editor / useEditor	consumer	1.6 KB / 248 B	None	None	None
⚪ @portabletext/html / @portabletext/html	export	69.3 KB / 10.1 KB	None	4 ms	+0 ms, +0.9%
⚪ @portabletext/html / @portabletext/html/rules	export	15.2 KB / 2.1 KB	None	3 ms	-0 ms, -0.0%
⚪ @portabletext/html / htmlToPortableText	consumer	69.3 KB / 10.1 KB	None	None	None
⚪ @portabletext/keyboard-shortcuts / @portabletext/keyboard-shortcuts	export	7.0 KB / 858 B	None	1 ms	-0 ms, -1.1%
⚪ @portabletext/markdown / @portabletext/markdown	export	425.4 KB / 66.1 KB	None	23 ms	+0 ms, +0.1%
⚪ @portabletext/markdown / portableTextToMarkdown	consumer	338.8 KB / 56.3 KB	None	None	None
⚪ @portabletext/patches / @portabletext/patches	export	50.0 KB / 7.7 KB	None	3 ms	+0 ms, +1.1%
⚪ @portabletext/plugin-character-pair-decorator / @portabletext/plugin-character-pair-decorator	export	124.1 KB / 15.8 KB	None	None	None
⚪ @portabletext/plugin-decorations / @portabletext/plugin-decorations	export	16.4 KB / 2.3 KB	None	None	None
⚪ @portabletext/plugin-dnd / @portabletext/plugin-dnd	export	10.4 KB / 1.8 KB	None	None	None
⚪ @portabletext/plugin-emoji-picker / @portabletext/plugin-emoji-picker	export	150.1 KB / 18.6 KB	None	None	None
⚪ @portabletext/plugin-input-rule / @portabletext/plugin-input-rule	export	124.2 KB / 15.8 KB	None	None	None
⚪ @portabletext/plugin-list-index / @portabletext/plugin-list-index	export	7.4 KB / 1.1 KB	None	None	None
⚪ @portabletext/plugin-markdown-shortcuts / @portabletext/plugin-markdown-shortcuts	export	136.4 KB / 17.6 KB	None	None	None
⚪ @portabletext/plugin-one-line / @portabletext/plugin-one-line	export	2.6 KB / 608 B	None	None	None
⚪ @portabletext/plugin-paste-link / @portabletext/plugin-paste-link	export	4.3 KB / 1.0 KB	None	None	None
⚪ @portabletext/plugin-sdk-value / @portabletext/plugin-sdk-value	export	242.1 KB / 32.8 KB	None	None	None
⚪ @portabletext/plugin-table / @portabletext/plugin-table	export	61.1 KB / 7.1 KB	None	None	None
⚪ @portabletext/plugin-table / @portabletext/plugin-table/ui	export	114.6 KB / 19.5 KB	None	None	None
⚪ @portabletext/plugin-typeahead-picker / @portabletext/plugin-typeahead-picker	export	166.1 KB / 19.9 KB	None	None	None
⚪ @portabletext/plugin-typography / @portabletext/plugin-typography	export	131.1 KB / 17.0 KB	None	None	None
⚪ @portabletext/repair / @portabletext/repair	export	4.5 KB / 636 B	None	2 ms	+0 ms, +3.3%
⚪ @portabletext/sanity-bridge / @portabletext/sanity-bridge	export	275.1 KB / 30.2 KB	None	94 ms	+0 ms, +0.3%
⚪ @portabletext/schema / @portabletext/schema	export	9.9 KB / 1.2 KB	None	1 ms	-0 ms, -4.6%
⚪ @portabletext/toolbar / @portabletext/toolbar	export	153.3 KB / 17.3 KB	None	None	None
⚪ @portabletext/toolbar / typical	consumer	145.6 KB / 16.9 KB	None	None	None

Significant means at least 1.0 KB and 1% gzip, or at least 5 ms and 10% import time.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f8561d2. Configure here.}