Please create a task to remove Experimental with target 1.13

Shouldn't we remove the flag itself, in 1.12 or so?

Yes, we need to:

• remove the flag itself from ComposeUiFlags
• keep the ComposePanel/ComposeWindow property, remove Experimental from it
• do that in 1.13, as we release this API in 1.11

Created https://youtrack.jetbrains.com/issue/CMP-9290/Update-click-to-clear-focus-flags

Android moved this flag to a ComposeView property.

It is probably legit to set different values for different cases, so I propose to do the same in ComposeWindow, ComposePanel and Window composables (still keep it experimental).

Cases in my mind where you don't want to clear focus:

• IntelliJ interop
• text editors (keep focus in editor when you click on a toolbar or a scrollbar)

The value needs to be available in BaseComposeScene. What is the correct way to pass it there?

SceneContext or PlatformContext

Note that this is not only a desktop feature, so we will need flags in iOS and web interop entry points.

It should provide working-no-op impl and must keep optional for platforms to implement

IntelliJ interop

If we want to provide seamless interop, we need to keep this ability, as It doesn't clear focus on an empty space (open Settings, focus the Search field, click on an empty space).

text editors

Not so sure if it is right to configure it on global level, but from UX perspective It may look bad when the app loses focus out of the editor when I press on scrollbar, statusbar or toolbar (for example to switch to Bold)

If it's not standard desktop behavior to clear focus, then indeed we should allow both options.

I checked native apps and:

• it clears focus in WinUI (new Windows API) apps
• it doesn't clear focus in Win32 apps (old Windows API)
• it doesn't clear focus in AppKit apps

My experiments:

• Windows (doesn't clear)

  • File properties
  • Notepad
  • Nvidia Control Panel (seems uses Win32 API)

• Windows (clears)

  • Settings
  • Paint

• macOS (doesn't clear)

  • Settings
  • File properties
  • TextEdit save window
  • Choose file dialog (Search field)
  • Grapher
  • Activity monitor main table

• macOS (clears)

  • Activity monitor search field
  • Finder search field

If we go with the logic that behaviors need to be controlled per entry point, we should allow controlling from the entry point most behaviors currently controlled by global flags

We can follow the strategy - if we think the lack of configurability can introduce significant flaws, then we need to add configurability. Lack of configurability of the first focused element seems doesn't introduce significant flaws.

It's not about the configurability itself, but about the granularity at which we need the configurability. Is per-application configurability enough, or do we need something more granular? Per window? Per entry point? Per element?

Is per-application configurability enough, or do we need something more granular

Per-application granularity for temporary flags is enough. Granularity for something permanently configurable should be lower, at least because of common code principles ("no globals"), and because of different use cases in different part of the application.

Ideally it should be not just some property, but just an ability to achieve the desired behavior. In our example - the previous behavior (without clearing focus) was more configurable, because users that want to clear focus could just add a focusable background. And users that don't want to clear focus - just keep the default behavior. With the new feature, users that don't want to clear focus have no option.

Per-application granularity for temporary flags is enough

Personally I would create a common class that we can pass to every entry point, it looks better design in my eyes, but it is not so important. More important is to keep the established AOSP design for temporary flags.