Custom Action keyboard shortcut does not trigger, but action works from context menu

[Marco Rebellato]

A custom action defined in SourceTree executes correctly when triggered via the right-click context menu, but does not execute when using the assigned keyboard shortcut.

I'm using SourceTree on windows, version 3.4.30.0

[Tomislav Tobijas]

Hey @Marco Rebellato ,

From my experience, this can be due to specific configuration conflicts (or app focus).

What you can check:

• UI Focus Requirements: Sourcetree shortcuts often require the application focus to be on a specific panel. Ensure your cursor is active within the Log/History view or the File Status list before pressing the shortcut.

• Shortcut Conflicts: Verify that the assigned key combination is not being intercepted by another global Windows application or a native Sourcetree shortcut. Try reassigning the action to a unique combination, such as Ctrl + Shift + Alt + [Key], to test if it triggers.
  👆 This is where I have issues with other programs/apps as well 👀

• Modifier Key Behavior: In some Windows environments, certain modifier keys (like Alt) may trigger the application menu instead of the custom action. Ensure your shortcut does not conflict with standard Windows menu navigation

Can you try checking this and see how it goes?

Cheers,
Tobi

[Marco Rebellato]

Hi Tobi,

Thanks for the suggestions.

I’ve tested this further and ruled out the common issues:

• Focus is definitely on the commit log view, on a specific commit in this case.
• Restarted SourceTree and my machine
• Avoided Alt-only combinations to prevent menu interference

I also tried several non-conflicting shortcut combinations, including:

• Ctrl + Shift + K
• Ctrl + Shift + J
• Ctrl + Shift + .
• Ctrl + Shift + Alt + F9

In all cases, the result is the same:

• The custom action works via the right-click menu
• The assigned shortcut never triggers

I can try testing on a different PC to see whether the issue can be recreated.

Let me know if there’s any logging I can enable to help investigate further.

Thanks,
Marco

[Marco Rebellato]

Hey Tobi,

Quick update on this.

I tested the behaviour on a colleague’s machine and the shortcut worked there (using a simple test PowerShell action). I then repeated the same test on my machine by creating a new custom action, and the shortcut also worked.

This suggests the issue isn’t with shortcuts in general, but specifically with existing custom actions. It looks like updating or reassigning a shortcut on an existing action doesn’t take effect correctly, whereas newly created actions do work as expected.

It might be worth investigating whether this is a bug related to updating existing custom actions.

For now I’ll stick to creating new actions instead of updating existing ones.

Thanks,
Marco

[Tomislav Tobijas]

Thanks for further troubleshooting and sharing the resolution here @Marco Rebellato !

I've tried (really quickly) to scan JAC for open features or bugs related to this, but couldn't find anything. You could maybe do another scan, but I believe you can also create a new bug (for this specific version) on there > this will probably make it land on the dev/product team backlog, so they can do a further check 👀

[Marco Rebellato]

Following up on this, resetting the custom actions config does restore shortcut functionality, but only temporarily.

After restarting my computer, the shortcuts stopped triggering again altogether, even for newly created actions, while the same actions continue to work via the context menu.

Deleting the customactions.xml file brings everything back to normal again, so it definitely seems like something related to how the shortcut bindings are stored or refreshed.

I’m probably not going to dig into this any further myself for now, as the behaviour seems a bit inconsistent and I don’t have a lot of time to keep investigating it properly.

So while resetting works as a temporary workaround, it doesn’t really fix the underlying issue.

Thanks,
Marco