Skip to main content

Prevent interaction hotspots from triggering below fixed elements

  • May 18, 2021
  • 54 replies
  • 6203 views
Show first post

54 replies

djv
Figmate
  • djv
  • Community Support
  • June 24, 2025

Hey All, thank you for your continued feedback! 

The team confirmed that this is not a bug; it’s currently expected behavior. This was a design decision to ensure that frames without interactions do not block interactions. All of your existing prototypes with interactions actually rely on this behavior to function, so implementing what you would consider a “fix” would likely cause other major prototyping bugs. 

Rest-assured, this is still being tracked as a feature request by the prototyping team to better understand how it is affecting the overall community. They’re now considering how to implement this in the best way that doesn’t cause other bugs. 

 

We appreciate your patience and understanding. 

JoeM
  • JoeM
  • New Participant
  • September 19, 2025

Hey All, thank you for your continued feedback! 

The team confirmed that this is not a bug; it’s currently expected behavior. This was a design decision to ensure that frames without interactions do not block interactions. All of your existing prototypes with interactions actually rely on this behavior to function, so implementing what you would consider a “fix” would likely cause other major prototyping bugs. 

Rest-assured, this is still being tracked as a feature request by the prototyping team to better understand how it is affecting the overall community. They’re now considering how to implement this in the best way that doesn’t cause other bugs. 

 

We appreciate your patience and understanding. 

 

It’s been 4 years since this issue was posted... All we need is a way to block hover-based interactions from firing behind elements that are in front of them. I.e. If the mouse is not active within the specific element that an interaction is set on, it shouldn’t fire.

Can’t believe this is still an issue in an app that is supposed to have “advanced” prototyping features… Meanwhile we’re getting all this AI garbage that nobody is even asking for.

    jmt
    • jmt
    • New Member
    • June 10, 2026

    Still not resolved.

    djv
    Figmate
    • djv
    • Community Support
    • June 10, 2026

    Hey All,
     

    Since my last reply, I've continued to share this thread with the prototyping team. Please know that the volume of feedback here has not gone unnoticed. 53 replies is a strong signal, and it's been useful in helping the team understand how broadly this impacts real workflows.
     

    The team is still working through how to implement a solution that gives you the control you're looking for without inadvertently breaking existing prototype behaviors that depend on the current pass-through logic. It's a nuanced problem, and they want to get it right. I don't have a timeline to share, and I'd rather be honest about that than give you a date I can't stand behind. What I can say is that this remains an open, tracked request.

     

    In the meantime, the most reliable temporary solution continues to be placing your scrollable content in a nested clipped frame with overflow scrolling enabled on that inner frame, keeping fixed elements outside the scroll container. It won't work for every setup (transparent navs in particular), but it's the most consistent path for now. I'll update this thread if there's anything new to share. Thanks for your continued patience.

    Terms & ConditionsAccessibility statement