Skip to main content

Issue:
When using the "While Hovering" interaction on a component, the hover state can become stuck — meaning it remains active even after the cursor leaves the element. This is especially noticeable when hovering over multiple instances of the same component in a prototype. The hover state lingers on all previously hovered items instead of resetting properly.
 

Steps to Reproduce:

  1. Create a component with default and hover variants.

  2. Add a “While Hovering → Change to hover” interaction.

  3. Place multiple instances of the component in a layout.

  4. Preview the prototype.

  5. Hover over several instances one after another.

  6. Previous components stay in their hover state, even after the cursor leaves.
     

Expected Behavior:
Only the element currently being hovered should show its hover state. Others should reset to default.
 

Actual Behavior:
Multiple elements end up stuck in their hover state, even though the cursor is no longer hovering them.
 

Additional Notes:
This issue was first reported over 4 years ago, and it still hasn’t been resolved. It significantly affects the reliability of interactive prototypes and is disruptive during user testing, as users are confused by lingering UI states that shouldn’t be active.

Some people suggest using "Mouse Enter" and "Mouse Leave" as a workaround, but this doesn’t work well when hover states include buttons that trigger overlays — the hover state disappears too quickly, closing the overlay or breaking the interaction flow.

Hmmm. I did that and it seems to work fine for me.

 

or maybe that only happens when the layout is complex or really big? not sure though


@Raphael_M , thanks for your reply. It is actually quite difficult to reproduce on the spot, since it only happens every now and then. But when it happens it is a persistent issue. The only temporary fix is to completely reload the prototype tab.

Once it happens again I’ll make sure to capture a video of it. 

Here is also another topic that adresses the same issue with many other users experiencing it as well: 

 


I’m having the same issue! When you play the prototype, it works okay, but after messing with it for a while the buttons states start to stick to “hovered”. 

 

My prototype link: https://www.figma.com/proto/seqeBfGUJQN3UdOO1v4jby/Love-Vet---Design-System?page-id=54941%3A84529&node-id=54941-84874&viewport=5813%2C1995%2C0.41&t=hcFImF3seR0WwlkW-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=54771%3A74389&show-proto-sidebar=1


This is such a basic feature and the fact that it is STILL not fixed after YEARS of reports about it is why I use penpot whenever possible now.


The original report was closed for some reason and yet the problem persists. When I set mouse enter / mouse leave on a prototype, because While Hovering is hopelessly broken, changing one of these two interactions changes BOTH of them to the same thing.

Steps:

  1. Set interaction to “Mouse enter - Change to - hover” (on both the hover and default states)
  2. Add another interaction with “Mouse leave - Change to - default” (on both the hover and default states)
  3. Check the “Mouse enter...” interaction...it says “Change to - default”.
  4. Change it back to “...hover”
  5. Check “Mouse leave...”: it says “Change to - hover”
  6. Scream into the void that is the clearly completely uninterested Figma Product team.

Hey All, thanks for following up on this issue! 

 The team confirmed that this is a long-standing bug that occurs when variables are used in a prototype. While I can't promise a quick fix, please know that our engineering team is aware of the issue and are still working towards finding a solution in the future. 

As a temporary solution, others in the community have worked around this bug by using variants instead of variables.  While I know it is not ideal, using variants instead of variables for interactions, should avoid this issue from occurring.

We appreciate your patience and understanding. 


Reply