Fix background Chrome fill timeouts

[alexanderradahl]

Problem

chrome_fill could hang until the 45-second native-host/client timeout in inactive MDB tabs. The fill path set the field value and then awaited two requestAnimationFrame callbacks to verify framework retention. Chrome may suspend animation frames indefinitely in background tabs, so the extension never returned a response even though navigation and snapshots remained healthy.

This blocked Reddit comments and other input/textarea interactions in the background browser.

Fix

• Keep the preferred two-animation-frame framework settle path.
• Add a 250 ms fallback so an inactive tab can never wait on animation frames alone.
• Preserve sticky-value verification and the existing retry/error behavior.
• Bump the unpacked extension to 0.2.8.
• Add a runtime regression that executes the actual serialized pageFill function with requestAnimationFrame permanently suspended and proves it resolves with the retained value.

Verification

• npm run check — passed
• node tests/chrome-fill-background.mjs — passed in ~250 ms with rAF never firing
• node tests/chrome-background.mjs — passed
• npm test — passed, including smoke, integration, adversarial, Responses, HTTP, OAuth, PTY, federation, ChatGPT conversation/runtime, browser, and installer suites

No browser/provider write is performed by the source change itself.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 113730f64a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Synchronize the runtime version with the manifest

Bumping only the manifest leaves VERSION in service-worker.js at 0.2.7. After installing this 0.2.8 extension, the native-host ready message and the status and extension.reload responses therefore still identify it as 0.2.7, preventing callers and diagnostics from confirming that the updated worker is actually running. Update the runtime constant as part of this version bump, or derive it from chrome.runtime.getManifest().version.

Useful? React with 👍 / 👎.