Expose Flutter debug toolbar extension group

[mdddj]

What changed

• exposed a new public action group id: Flutter.DebugProcess.TopToolbar
• appended that group after Flutter's built-in debug toolbar actions in FlutterDebugProcess
• applied the same hook to Flutter test and Bazel test debug toolbars
• kept the group hidden when no downstream plugin contributes actions

Why

FlutterDebugProcess.registerAdditionalActions() currently builds the top run/debug toolbar directly from code by mutating the runtime DefaultActionGroup. That makes the toolbar effectively closed to dependent plugins: there is no public action group id and no extension point they can target from plugin.xml.

Exposing a dedicated inline ActionGroup is the smallest platform-native way to make this extensible. Downstream plugins can now contribute with standard IntelliJ action registration, for example:

<action id="..." class="...">
  <add-to-group group-id="Flutter.DebugProcess.TopToolbar" anchor="last"/>
</action>

This avoids adding a new custom EP just to append toolbar actions, keeps the existing toolbar construction intact, and preserves current behavior when nobody contributes anything.

Validation

• ./gradlew buildPlugin

[gemini-code-assist]

Code Review

This pull request introduces a mechanism for third-party plugins to contribute inline actions to the Flutter run and debug content toolbars. It defines a new action group, "Flutter.DebugProcess.TopToolbar", in plugin.xml and implements a utility class, FlutterDebugProcessActions, to handle the dynamic addition of these extension actions. The integration is applied across FlutterDebugProcess, BazelTestDebugProcess, and TestDebugProcess. I have no feedback to provide.

[helin24]

Thanks for the contribution! This isn't something we've thought about at all, so can you provide some more context of what a dependent plugin will be able to do if we provide this extension point? e.g. would this likely be to move the Flutter actions around more easily? Or an example of how you would accomplish an equivalent UI with and without this code?

[mdddj]

I’m developing a Flutter plugin called FlutterX, and I’d like to add some custom Actions to this toolbar.

I tried several approaches, but after digging into the source code, I found that the toolbar is created and populated directly in code.

Would you consider exposing some extension points for third-party plugins that depend on the Flutter plugin, so they can contribute their own actions to this toolbar?

[helin24]

Thanks for explaining more @mdddj ! Exposing this extension sounds good; I'm not totally following how the code works, so if you can explain a bit more or show me an example of how the plugin.xml will look for your plugin, that may help.

[mdddj]

Thanks, this is a good question.

The goal here is not to let downstream plugins reorder or replace Flutter’s existing toolbar actions. It is only to provide an extension point after the built-in Flutter debug/test actions, so plugins that depend on the Flutter plugin can contribute additional inline actions there.

Flutter.DebugProcess.TopToolbar is an ActionGroup, not a single action. A dependent plugin contributes actions to that group from its own plugin.xml, and this code looks up that group via ActionManager and appends it to the toolbar. Since the group is declared with popup="false", its children are rendered inline on the toolbar, so this can expose multiple actions rather than just one.

For example, a dependent plugin could contribute:

<actions>
  <action id="FlutterX.AttachFoo"
          class="com.example.flutterx.AttachFooAction"
          text="Foo">
    <add-to-group group-id="Flutter.DebugProcess.TopToolbar" anchor="last"/>
  </action>

  <action id="FlutterX.AttachBar"
          class="com.example.flutterx.AttachBarAction"
          text="Bar">
    <add-to-group group-id="Flutter.DebugProcess.TopToolbar" anchor="last"/>
  </action>
</actions>

[helin24]

@mdddj thanks for the example! This makes sense, though I suppose the name addAction is a bit of a misnomer given that an action group can be added there.

[helin24]

Sorry I'm asking for so many comments! I'm hoping they will reduce confusion for anyone looking at the code in the future.

[helin24]

Thanks for addressing all of the questions! I'll let @pq review and merge.

[pq]

Thanks for the thoughtful explanation. LGTM!

[pq]

Hey! It looks like we're hitting an issue during plugin verification.

* Override-only method com.intellij.openapi.actionSystem.ActionGroup.getChildren(AnActionEvent) is invoked in io.flutter.run.FlutterDebugProcessActions.isEmpty(ActionGroup) : boolean. This method is marked with @org.jetbrains.annotations.ApiStatus.OverrideOnly annotation, which indicates that the method must be only overridden but not invoked by client code. See documentation of the @ApiStatus.OverrideOnly for more info.

https://github.com/flutter/flutter-intellij/actions/runs/25895252883/job/76564968851?pr=8905

Could you investigate? Is there a way to accomplish this with supported APIs?

[mdddj]

Thanks for catching this. I replaced the manual getChildren(null) expansion with a DefaultActionGroup check using
getChildActionsOrStubs(), since this group is declared statically in plugin.xml. Pushed the fix in 56f2e13.

[pq]

Awesome. Thanks a million, @mdddj!

[pq]

Sorry. Last thing, I promise.

Could you add yourself to AUTHORS?

Thanks!

[mdddj]

Done, added myself to AUTHORS. Thanks!

[auto-submit]

autosubmit label was removed for flutter/flutter-intellij/8905, because This PR has not met approval requirements for merging. Changes were requested by {pq}, please make the needed changes and resubmit this PR.
The PR author is not a member of flutter-hackers and needs 1 more review(s) in order to merge this PR.

• Merge guidelines: A PR needs at least one approved review if the author is already part of flutter-hackers or two member reviews if the author is not a member of flutter-hackers before re-applying the autosubmit label. Reviewers: If you left a comment approving, please use the "approve" review action instead.

[pq]

Thanks!