You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Auto-launch and attach(): reports carry no JS wrapper details, and Android records unfiltered and unmasked until JS installs filters and <BugseeSecure> #134
Found while documenting the 7.x beta (docs PR bugsee/docs#110). Checked against the source on main at 7.0.0-beta3; file:line references are to the SDK repo unless a repo is named. Not reproduced on a device unless a line says so.
1. attach() never registers the wrapper's JS details
Only launch and relaunch call registerWrapper() (src/index.ts ~145, 173, 692-698); there is no other setWrapperInfo call site. Under the Expo plugin's autoLaunch the app calls Bugsee.attach(), so for the whole session every report carries only the thin identity registered natively at process start (ReactNativeWrapperInitProvider.java, BGSRNWrapper wrapperWithoutJsRuntime): type and version, without context (React Native version, JS engine, dev build, build configuration).
2. Android auto-launch records before JavaScript runs
With autoLaunch the Android SDK starts at process start from manifest meta-data, so JS launch options are never applied (the app has to call relaunch(options) after attach()), and:
the JS log, network and breadcrumb filters are installed natively only when setLogFilter / setNetworkFilter / setBreadcrumbFilter run (NetworkFilterBridge.java:174, BreadcrumbFilterBridge.java:158; LogFilterBridge passes lines through with no user callback), so everything captured before is recorded unfiltered;
nothing from <BugseeSecure> / setSecureRectangles is masked until those mount (password-field detection and FLAG_SECURE masking are independent of them).
The docs now say this (privacy overview, Expo page); it is a privacy-relevant default.
Suggested direction
Make attach() register the full wrapper identity (the same registerWrapper() as launch), or have the native init read the context.
Either document auto-launch as unsuitable when filtering or masking must apply from the first frame, or make the native side hold capture until the JS side has installed (or declared it has no) filters: for example a manifest flag for "filters will be installed from JS" that keeps the filter bridges fail-closed until setXFilter or an explicit "none" arrives.
Activity
Docs: accurate reload semantics, no-RN process, autoLaunch scope for …
Startup hold: retry a failed early install, start the watchdog from t…
Install guard: no catch-and-rethrow, so the raw-message scan passes (#…
LogFilterBridge: publish the hold only after a successful install, ro…
Auto-launch: attach() registers the wrapper identity; opt-in fail-clo…