The dart language team will soon be changing the behavior of the language so that an invocation of a private class members won't get dispatched to a noSuchMethod method in another library; instead an exception will be thrown. This is a necessary prerequisite to allowing promotion of private fields (dart-lang/language#2020). It also closes an important privacy loophole in the language, by ensuring that the user can see all the possible behaviors of a private member invocation without having to look outside of the library.

This has an important consequence for tests using mockito, in the scenario where a private class member is referenced from outside of its containing class, and the containing class instance is replaced with a mock, but the reference isn't replaced with a mock. Previously, in this scenario, the invocation would be dispatched to Mock.noSuchMethod; with the upcoming language change it will throw an exception.

This situation arises with NavigatorObserver._navigator, which is referenced from the NavigatorState class; if a test mocks NavigatorObserver but not NavigatorState, it will likely fail. It could be argued that such tests should be rewritten to use a less brittle mocking strategy, but there are enough examples of this pattern in Google's internal code base that it seems likely that it exists in code belonging to other customers too.

After discussion with @goderbauer, we believe the best approach to avoid a widespread breakage is to rework NavigatorObserver in a way that preserves its user-facing API, but so that it doesn't contain a private member that's referred to by other classes.