feat: multi-browser web watcher via Accessibility Service#151
feat: multi-browser web watcher via Accessibility Service#151FractalMachinist wants to merge 6 commits intoActivityWatch:masterfrom
Conversation
Picks up PR #547 (merged Dec 2025) which fixes a panic in jstring_to_string when JNI passes modified UTF-8 strings (e.g. app names containing emoji). The old CStr::to_str().unwrap() path would abort on surrogate pairs; the fix uses jstr.into() which handles the JNI encoding correctly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Firefox ~v130+ uses a Jetpack Compose toolbar where the URL lives in the content-desc of a node with viewIdResourceName "ADDRESSBAR_URL_BOX". Two issues prevented the original approach from working: 1. findAccessibilityNodeInfosByViewId silently returns empty for IDs that don't contain ":" (requires "package:id/name" format); bare Compose testTag names like ADDRESSBAR_URL_BOX are rejected. 2. The toolbar is a sibling of the WebView content area, so searching from event.source never reaches it. Fix: use rootInActiveWindow as search root and traverse the tree manually with findNodeByResourceName (compares viewIdResourceName directly). The view-based fallback IDs (url_bar_title, mozac_browser_toolbar_url_view) are retained for older Firefox versions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
If findWebView(child) returns child itself (i.e. the child IS the
matching WebView), the previous .also { child.recycle() } destroyed the
node before the caller could use it. Only recycle when the returned node
is not the child being searched.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rowser When a supported browser's URL extractor returns null, dump the full accessibility tree to logcat at debug level (tag: WebWatcher), rate-limited to once per minute per browser package. This gives bug reporters actionable data — the actual view IDs and content descriptions present — without requiring manual instrumentation. Addresses the unresolved Samsung Internet and Chrome reports from the original PR, where no logs were available to diagnose the failure. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Greptile SummaryThis PR replaces the Chrome-only
Confidence Score: 3/5Two production P1 bugs and one test P1 bug should be fixed before merging. Three P1 findings are present: an AccessibilityNodeInfo memory leak in findNodeByResourceName (the same class of bug the PR explicitly fixed in findWebView), a potential NPE in the accessibility event catch block that silently kills event processing, and a test synchronization bug that undermines the reliability of the new instrumentation tests. WebWatcher.kt (recycle bug + NPE) and CustomTabsWrapper.kt (queue not consumed) Important Files Changed
Sequence DiagramsequenceDiagram
participant Browser
participant WebWatcher
participant findNodeByResourceName
participant findWebView
participant RustInterface
Browser->>WebWatcher: onAccessibilityEvent(event)
WebWatcher->>WebWatcher: shouldIgnoreEvent()?
WebWatcher->>WebWatcher: urlExtractors[packageName]
alt Known browser (Firefox)
WebWatcher->>findNodeByResourceName: rootInActiveWindow, "ADDRESSBAR_URL_BOX"
findNodeByResourceName-->>WebWatcher: urlNode (contentDescription)
WebWatcher->>WebWatcher: extractFirefoxUrl → newUrl
else Known browser (Chrome/Edge/etc.)
WebWatcher->>WebWatcher: extractTextByViewId(event, viewId) → newUrl
end
alt newUrl == null
WebWatcher->>WebWatcher: maybeDumpTree(packageName) [rate-limited 1/min]
else newUrl != null
WebWatcher->>WebWatcher: handleUrl(newUrl, browser)
WebWatcher->>findWebView: event.source
findWebView-->>WebWatcher: WebView node (title text)
WebWatcher->>WebWatcher: handleWindowTitle(title)
WebWatcher->>RustInterface: heartbeatHelper(bucket_id, start, duration, data)
end
|
|
I think you mentioned wrong account :) |
adding a generic WebWatcher that tracks browser URLs via Android's Accessibility Service. Verified Firefox working on Android 14 (Fairphone 6).
What this adds
ChromeWatcherwith aWebWatchersupporting Chrome, Firefox, Samsung Internet, Opera, and Edgeurl,title,browser,audible, andincognitofields per theweb.tab.currentevent typeFirefox Compose toolbar fix
Firefox ~v130+ migrated its address bar to Jetpack Compose. The original PR's approach (
findAccessibilityNodeInfosByViewId("ADDRESSBAR_URL_BOX")) silently returns empty results because Android requires IDs in"package:id/name"format and rejects bare Compose testTag names. Additionally, the toolbar is a sibling of the WebView content area, so searching fromevent.sourcenever reaches it.Fix: search from
rootInActiveWindowand traverse the tree manually, comparingviewIdResourceNamedirectly. The view-based fallback IDs (url_bar_title,mozac_browser_toolbar_url_view) are retained for older Firefox versions.Fixes from code review
findWebViewwherechild.recycle()was called even whenchildwas the node being returned, leaving the caller with a recycled reference (flagged by ellipsis-dev in the original PR).Testing
Verified on one physical device (Fairphone 6, Android 14) with Firefox 138. Chrome, Edge, Samsung Internet, and Opera have not been tested by the authors of this revision — the view IDs for those browsers are carried over from the original PR unchanged. The diagnostic tree logging (described below) was added specifically because we lack broad device/browser coverage. If you or a reviewer can test on Chrome or Samsung Internet and URL extraction fails, enabling debug logging (
adb logcat -s WebWatcher:D) will produce a dump of the accessibility tree that should make it straightforward to identify the correct view IDs. We believe the Firefox fix is correct because it was verified end-to-end (URLs and page titles appearing in the ActivityWatch timeline). We believe the recycle fix is correct by code inspection. For the untested browsers, confidence rests entirely on the original PR author's view IDs being stable across the versions you'll encounter.Diagnostic logging for unresolved browser issues
The original PR had unresolved reports of Chrome stopping mid-session and Samsung Internet never producing data. The Chrome issue was almost certainly the JNI emoji crash described below — the service would crash silently and stop processing events. For future reports,
WebWatchernow dumps the full accessibility tree to logcat (tag:WebWatcher, debug level) when a known browser's URL extractor returns null, rate-limited to once per minute per browser. This gives reporters actionable data without manual instrumentation.aw-server-rust submodule bump
This PR bumps
aw-server-rustto current master to pick up PR #547, which fixes a panic injstring_to_stringwhen JNI passes modified UTF-8 strings (e.g. app names containing emoji). Without this fix the service crashes silently on any heartbeat where the browser has a non-BMP character in its app name, which likely explains the "Chrome stopped working" report in the original PR thread.Happy to separate the submodule bump into a standalone PR if you prefer to take it independently.
Credits
Original implementation by @KonradKrol (incubly-oss/aw-android#138).