docs(flutter): state that Dart network capture needs both the option and the overrides - #32
Merged
Merged
Conversation
…and the overrides /sdk/flutter/configuration listed monitorNetwork with a default of true, while /sdk/flutter/network said the handler "has to be installed explicitly". Read separately, the first implies Dart traffic is captured out of the box and the second implies it is opt-in. Neither said the two are both required. Verified against cross/flutter and android/sdk: - lib/src/constants.dart:12 - constOptionMonitorNetwork = true. - lib/src/options.dart:135 - monitorNetwork maps to the "MonitorNetwork" key; android/src/.../BugseePlugin.java:542 forwards it to the native Options.CaptureNetwork. - lib/src/networking.dart never reads the option. Dart interception is gated purely on HttpOverrides.global being set to Bugsee.defaultHttpOverrides, so without it Dart requests are never seen no matter what monitorNetwork says. - Setting monitorNetwork to false does still suppress Dart traffic, just further down: the native capture provider is annotated @BugseeCaptureControllingOptions(Options.CaptureNetwork) and only subscribes to the network dispatcher when started, so forwarded events are dispatched to nobody. The privacy page's "disabled completely" claim is therefore accurate; it just did not say what "completely" covers. So both conditions are necessary and neither page said so. network.md now lists them as two numbered requirements with a note explaining which layer each governs, the two configuration.md rows cross-reference it, and privacy/network.md spells out that disabling wins over the overrides. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Change-Id: I3d7c38346c9bd03df6b4e99dcf97356ef6415447
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves the open question: "is Flutter's
monitorNetwork: truedefault meaningful withoutHttpOverrides.global?"Answer: no — both are required, and neither page said so. Verified in
cross/flutterandandroid/sdkrather than inferred from the docs.What the code actually does
lib/src/constants.dart:12constOptionMonitorNetwork = truelib/src/options.dart:135monitorNetwork⇄ the"MonitorNetwork"keyandroid/src/…/BugseePlugin.java:542put("MonitorNetwork", Options.CaptureNetwork, COERCE_BOOL)— forwarded to the native optionlib/src/networking.dartHttpOverrides.globalA reader of
configuration.mdalone concludes Dart HTTP is captured by default. It is not —package:httpand anything else ondart:io'sHttpClientis invisible to Bugsee until the overrides are installed.One thing I checked and was wrong about
I initially suspected the reverse was also broken — that
monitorNetwork: falsewould fail to stop Dart traffic, sincenetworking.dartignores the option. That would have been a privacy hole, so I traced it rather than asserting it:BugseeNetworkInterceptionCoordinator.getNetworkEventConsumer()is documented "Always non-null… the same instance for the lifetime of the process", socreateNetworkEventdoes not return null when capture is off.BugseeCaptureDataProviderNetworkis annotated@BugseeCaptureControllingOptions(Options.CaptureNetwork)and only subscribes to the dispatcher when started.Net: with
monitorNetwork: falsethe event is created and dispatched to nobody. Traffic is suppressed. The privacy page's "disabled completely" claim is correct — it just never said what "completely" covers, which this PR adds.Changes
network.md— the two requirements as a numbered list, plus an:::infoexplaining which layer each governs.configuration.md— bothmonitorNetworkrows cross-reference it.privacy/network.md— states that disabling covers Dart and native, and wins over the overrides.Checks
npx cspell288 files / 0 issues ·npm run buildsucceeds, no broken links🤖 Generated with Claude Code