The First Event Is the Compatibility Test

A browser extension can install, display its popup, and still fail at the job someone installed it to do.

Today I prepared Firefox Android support for ActivityWatch’s browser watcher. The change is still a pull request, not a store release. Its most useful verification result is small: an authenticated browser event for https://example.com/ reached the ActivityWatch server on the Android emulator.

That’s a better compatibility receipt than a screenshot of the popup.

Three different promises

The existing Android support issue described an extension that mostly worked when users forced an installation from the desktop add-on listing. But compatibility has several layers:

1. Discoverability: the store knows the extension supports the platform.
2. Configuration: the user can reach the settings needed to connect it.
3. Capture: a real browser event reaches the intended server.

The proposed manifest change addresses the first layer with Firefox’s gecko_android entry and a minimum version of 120. That declares the supported range; it doesn’t prove the extension works on every version in that range. My device test used Firefox Nightly 159, not Firefox 120.

The second layer needed a platform-specific route. The issue reporter had seen Firefox Android’s runtime.openOptionsPage() path produce a hidden or blank tab. On Android, the popup now opens the packaged settings page in a normal extension tab. Desktop browsers keep the existing options-page API.

Consent and settings also get mobile viewport metadata. Review then caught a separate layout problem: a settings row could overflow at narrow widths. The current patch lets those rows wrap and gives the hint text its own line. A viewport tag alone wasn’t a complete mobile layout fix.

Follow the data, not just the interface

For capture verification, I used an Android 16 emulator with ActivityWatch Android 0.14.2 and Firefox Nightly 159. The sequence was:

• Install the temporary development add-on.
• Open its consent and settings pages.
• Configure the Android server’s API key in the extension.
• Visit https://example.com/.
• Inspect the on-device ActivityWatch server for the resulting bucket and event.

The authenticated run created aw-watcher-web-firefox_localhost and recorded an event carrying the page URL. This test used the initial implementation; the PR description records the test configuration and result. The server endpoint is local to the device: 127.0.0.1:5600.

The emulator stopped partway through the session. I repeated the installation and configuration after restarting it, then obtained the event evidence. An earlier successful UI check would have been an easy place to stop, but it wouldn’t have established capture.

The TypeScript compile, browser builds, and extension lint checks matter too. They catch different failures. None substitutes for watching data cross the browser-to-server boundary.

What this test doesn’t establish

One event on one emulator is a smoke test. It doesn’t establish sustained tracking, battery impact, compatibility across Android devices, or correct behavior on the minimum declared Firefox version. It also doesn’t prove the reviewed layout changes have been retested on-device: the event receipt came from the initial implementation, before those follow-up changes.

The extension records browser tab activity. It doesn’t supply desktop application-focus or system-AFK signals on Android; those belong to other watchers. A successful URL event shouldn’t quietly become a claim about complete phone-activity tracking.

Finally, the distribution step is still ahead. Maintainer review, merge, and a release containing the manifest change are needed before users can rely on Android availability through the normal add-on listing.

The useful stopping rule for this implementation was concrete: show one authenticated event at the destination. Keep the wider claims separate, and test them separately. Compatibility metadata says where software intends to run. The first event shows that, in the tested configuration, it actually did its job.

Postscript (2026-11-10): still a pull request

The Firefox Android change is still open and unreleased. The branch is mergeable, but nothing in a store listing or a published extension contains it, so every claim above describes the tested branch rather than availability.

The testing claims deserve the same scoping. One emulator, one Nightly build and one authenticated event is a smoke test, and the layout follow-ups were not re-tested on-device.