Active UI panel locked during command execution

To reproduce...
1. Connect to a remote site and run a command/custom command over several items (enough to give you time to attempt other things)
2. Try to click on the other UI panel (in my case local) and you will notice that it will not become active.

This affects the use of keyboard shortcuts to perform actions in the local browser (or potentially other remote connection).

Build3918

When executing a custom command the active panel (browser) indicator is locked to prevent the user from accidentally changing the active side during execution which could lead to an unexpected or undesired outcome.

I reviewed the related code going back 6 months and the behavior remains the same now as it did back then.

Comparing 3814 to 3810 I am not seeing any changes even remotely related that might explain this new sudden change in behavior.

You are correct, tested an older version and this behavior is not new. I realized that i just happened to be doing something in a weird way... while I use running sessions to quick view/edit local stuff related to the task flashfxp is doing all the time it is usually during transfers.

I did notice however that even though the active side is locked, the user is still able to use the remote/local toggle and doing so while a command set is running breaks it (tries to send to local).

Thinking about this scenario more, I wonder if locking parts of the UI is the best route to take here? Processing a queue will function perfectly fine regardless of changes in the UI because it knows to send everything to a particular place... can the same method not be applied to other commands? I mean if you execute a command or set thereof in a remote connection should it not link that connection to the commands and inherit that link to all sub commands or child operations etc unless you explicitly tell it to do otherwise (eg /switch). Or is there some particular reason this approach would not work?

Correct only the active panel indicator is locked and this is done to prevent an accidental click from changing the active side which could change the outcome of the script, it does not disable or lock any other parts of the UI.

Some macro commands work on the basis that they are executing the command in the context of the active side in the active browser. (Off hand I do not recall which commands are effected by this)

Queued commands on the other hand automatically define the active side and browser in which the command should be executed and this is defined prior to executing the commands.

Whether or not this is the best approach I don't know, but I think it's better to do this than experience the pain of a critical script malfunction due to an accidental mouse-click.

Imagine doing a multi-level /cd that selected based on a text pattern and deleted the selected files, if the active indicator changed in turn effecting the behavior and files started being deleted from the other browser pane this would be devastating. (I don't know if this specific situation would be effected or not; but it's just an example)