Without seeing your code, I can only make vague statements about the problem. This answer represents my best guess based on the information provided so far.  

Decouple "Commands" from "Abilities"

The problem is that you have the same component responding to user input and driving the character. These are two separate responsibilities and should be two separate objects. The fact that you need to reliably do something in between when you finish receiving the Command and when you start performing the Ability is just one symptom of this.

The answer, I think, is to have the component that handles user input create a Command (or Instruction, or whatever else you want to call it) object, which it sends to the player.

The player would then hold on to the Command in a queued state until it's ready to perform it - for example, if it was in the middle of the animation to pick up an object, you wouldn't want to immediately start another action before that animation finishes and the object is stored in the player's inventory. (The "Queue" here would probably just be one action. If the UI issues 10 commands while the character is busy, the first 9 of them should be discarded leaving only the most recent one in the queue.)

Finally, at the moment when the Command is dequeued, the Player sets its state to Ability. Then it performs whatever command-specific code performs the actions that command is asking for (in some form where its end can be observed). Finally, when that code completes, the Player sets its state back to Idle (unless it has another Command queued in which case it moves on to whatever state is appropriate for that Command).

At no point does the implementation of the ability need to touch the player's state, unless it wants to put the player into a state other than Ability.