SelectionArea's selection should not be cleared on loss of window focus

[Renzo-Olivares]

This change fixes an issue where SelectionArea would clear its selection when the application window lost focus by first checking if the application is running. This is needed because FocusManager is aware of the application lifecycle as of #142930 , and triggers a focus lost if the application is not active.

Also fixes an issue where the FocusManager was not being reset on tests at the right time, causing it always to build with TargetPlatform.android as its context.

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
• I signed the [CLA].
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is [test-exempt].
• I followed the [breaking change policy] and added [Data Driven Fixes] where supported.
• All existing and new tests are passing.

[chunhtai]

is this for someone minimize the windows and resume it?

Also does this work for embedded flutter view?

[Renzo-Olivares]

Yeah this is for that case, or when someone clicks on a different applications window. I'm not too familiar with embedded flutter views and how they tie into the app lifecycle, but it seems at least for Android that a developer has to manually bridge the lifecycle events from their host application to the FlutterView https://docs.flutter.dev/add-to-app/android/add-flutter-view . I think if the lifecycle events are correctly bridged to their FlutterView that this should also work for them.

With regards to an embedded FlutterView in HTML, I used the sample https://github.com/flutter/samples/tree/main/web_embedding/ng-flutter to verify that the FlutterView was correctly receiving lifecycle events. Clicking onto an element in the host web page did not seem to trigger any changes to the app lifecycle. I only observed application lifecycle events triggered when clicking on a new tab, clicking on a different window, or different application outside the browser.

[chunhtai]

LGTM

[chunhtai]

maybe mention in which situation the lifecycle would not be resume.

[gspencergoog]

[Renzo-Olivares]

@chunhtai @gspencergoog I managed to track down the google testing issues. Some users modify the FocusManager.highlightStrategy in the setUp method of tests. This was easy enough to get around by saving the highlight strategy. However, the second issue is that some users add listeners to FocusManager in setUp. If we recreate an entirely new FocusManager at test time we lose all the listeners the user added. Not sure what the best way forward is here, this is my current attempt at fixing this 80ef35f but it exposes a public method on FocusManager.

Some other things I can think of is exposing some method in the TestWidgetsFlutterBinding that a user can call to rebuild FocusManager and that they should expect that any of their changes to FocusManager are not retained in that case. This means that anyone that wants an accurate FocusManager that listens to the application lifecycle would need to call this method in their test, which seems a little fragile.

[gspencergoog]

However, the second issue is that some users add listeners to FocusManager in setUp

In setUp, or in setUpAll? Because in setUp, they should expect that any state they setup there is destroyed once tearDown is called, and the next test should set it up again.

If they do it in setUpAll, that's more problematic, and the solution there is probably to just do it in setUp instead.

[Renzo-Olivares]

They add listeners in setUp, so I think we still need to retain the listeners across each individual test right? Right now there is an issue because we are setting a new FocusManager after setUp is called, which loses all the listeners that were set in setUp for a given test. setUp needs to happen first so FocusManager has the relevant platform context during construction.

[gspencergoog]

Ahh. So, could we instead initialize the FocusManager before the setUp, and then set the platform context after?

Since setUp is called before each test, I think the expectation would be that things don't revert after the setUp, but that reverting before the setup is fine (since it'll be reset to baseline).

[Renzo-Olivares]

I'm not sure I follow. If we initialize FocusManager before setUp we won't have the correct platform context during construction. The test variant is setup sometime after setUp is called, essentially at the same time the test body is run

flutter/packages/flutter_test/lib/src/widget_tester.dart

Lines 181 to 183 in a8a9b9b

	memento = await variant.setUp(value);
	maybeSetupLeakTrackingForTest(experimentalLeakTesting, combinedDescription);
	await callback(tester);

. We would ideally setup the test variant before setUp is called, so inside that method the user already has the correct defaultTargetPlatform for the given test (I think?), then we could initialize the FocusManager before setUp and it would have the correct platform context. That's a bit tricky to do though since the test is run asynchronously, I don't see a place where I could set up the test variant any earlier, unless we change the actual test_api to support running some callback before setUp. What do you think?

From what I understand this is the order of operations for a given test:
testWidgets -> test -> Declarer.test https://github.com/dart-lang/test/blob/84d2a2bcba0d63b9f4bd6cbf14fb7fc38621e65d/pkgs/test_api/lib/src/backend/declarer.dart#L171-L225 -> setUp (the setup method for a given test) -> test body (sets up the test variant and has the actual test logic for a given test).

[gspencergoog]

Actually, in effect, I guess I'm proposing the same thing that you are in the PR: your listenToApplicationLifecycleChangesIfSupported function is basically re-doing the FocusManager constructor bits that have to do with platform, which is what I was thinking about when I was saying to initialize it and then set the platform after.

I'm a little leery of adding that as a public API, though: I don't see any use for it outside of tests. Maybe mark it @visibleForTesting?

[Renzo-Olivares]

Oh okay I understand.

I agree, I am also not so sure about having it as a public API. The analyzer complains about visibleForTesting because it's not technically being used in a test, even though it's in flutter_test.

[gspencergoog]

Yeah, we should really fix the analyzer test to allow @visibleForTesting in the flutter_test repo. In any case, you can just add an exemption for it there.

[Renzo-Olivares]

Thanks for the suggestion! Done.

[gspencergoog]

Still LGTM

[gspencergoog]

Suggested change

	/// method after it has setup the test variant for a given test, so the
	/// this method after it has set up the test variant for a given test, so the

[gspencergoog]

Suggested change

	/// [FocusManager] can accurately listen to application lifecycle changes if
	/// [FocusManager] can accurately listen to application lifecycle changes, if