[Mac] - Should be able to disable pointer event pass through on gaining window focus

[matthew-carroll]

Consider a Mac desktop environment with multiple application windows open.

Historically, when the user taps on a non-focused Flutter window on Mac, that tap causes the window to receive focus, but it doesn't cause a tap event in the newly focused window. This is a nice feature because often only a small part of a window might be visible, so the user may not have a good place to tap to switch window focus. The user doesn't want to inadvertently tap a button that changes the content in the window.

In Flutter 3.3, it appears that a tap to focus a Flutter Mac window also sends a tap event, making it more difficult in some scenarios to switch focus without impacting the app.

For example, I'm currently debugging issues in SuperEditor related to text selection. My IDE and my Flutter window are on the same screen. I need to switch back and forth between them. Every time that I switch from my IDE to my Flutter window, by tapping the Flutter window, I inadvertently move the text selection somewhere else, because the tap to switch focus was handled like an intentional user interaction.

If this change was intentional, then I would suggest introducing control over this behavior.

Flutter version:

Flutter 3.3.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 18a827f393 (6 days ago) • 2022-09-28 10:03:14 -0700
Engine • revision 5c984c26eb
Tools • Dart 2.18.2 • DevTools 2.15.0

[huycozy]

Hi @matthew-carroll As I can see, Mac's windows still can receive focus and tap events from each other with one click (please see the demo below). It seems an expected behavior.

Demo

https://user-images.githubusercontent.com/104349824/194025765-91581290-1464-4f93-a9bc-8d9b73c8b8b9.mov

Could you provide a completed and minimal reproducible code sample so that we may verify the issue? Thank you!

[matthew-carroll]

What version of Flutter is running in your demo?

[huycozy]

@matthew-carroll I'm using Flutter stable 3.3.3 as yours.

[matthew-carroll]

@huycozy please try your same demo on Flutter 3.2 and see if there's any difference with your focus taps into Flutter.

[huycozy]

@matthew-carroll there is no Flutter 3.2 as I can see: https://docs.flutter.dev/development/tools/sdk/releases?tab=macos Or do you mean Flutter 3.3.2?

[matthew-carroll]

I mean whatever the last major release was. I guess it was 3.0.5.

[huycozy]

@matthew-carroll I see, there is a difference between Flutter releases:

• Flutter 3.0.5: doesn't cause a tap event in the newly focused window (Flutter window)
• Flutter 3.3.4 & 3.5.0: cause a tap event in the newly focused window (Flutter window)

It looks like a proposal to have this feature optional (enable/disable), right? Because I see that most of MacOS's windows can cause an event on the actionable elements (button/checkbox/dropdown, etc) in the newly focused window. In case we revert this, the Flutter window may not be consistent with other applications.

[matthew-carroll]

If this change was intentional, then yes, I'd like to request a feature to control it.

If this change was unintentional, then Flutter should probably change back to the original behavior.

One thing to keep in mind. Even though most application windows seem to follow this one-click behavior, I don't think browsers behave this way. For example, consider this text box that I'm typing into right now. Start with this text box unfocused. Give focus to some other desktop application. Then, tap into this text box in your browser. The browser becomes focused, but this text box doesn't receive focus. It requires a 2nd tap.

And here's a use-case example to appreciate the behavior. Imagine that you're looking at one app which displays a map, like Google Maps. You tap a location to display an address. You open another app to write down the address and phone number. You tap back to the map app, but you don't tap exactly on the destination. This causes the description with the address and phone number to disappear and select a different location instead.

The more complicated a UI gets, the more you tend to have popovers, selections, and other overlay information. These elements change if you select other content. It's very tedious to switch between application windows when you're trying to preserve that transient information.

[huycozy]

@matthew-carroll thanks for explanation and use cases. I'm not sure this change is intentional or unintentional so I will label this issue as an issue for further insights from the team.

[gspencergoog]

This was an intentional change to conform to native app semantics.

Converting this to a feature request.

(Desktop Triage)

[flutter-triage-bot[bot]]

The triaged-desktop label is irrelevant if there is no team-desktop label or fyi-desktop label.