Skip to main content
eokic-hexis
eokic-hexis
May 18, 2021

Prevent interaction hotspots from triggering below fixed elements

  • May 18, 2021
  • 54 replies
  • 6345 views

  1. Describe the problem your experiencing and how your idea helps solve this
    A scrollable (clickable) list of items triggers the interaction even if a fixed element overlaps it. Additionally, this bug occurs even if that overlaping element has a “Tap → None”

  2. Add as much context as possible (screenshots, Figma files, mockups, etc.)
    Stumbled upon this issue when I had to position an iOS keyboard on top of an interactive list of elements.

Demo file and steps to reproduce:

  1. Start the prototype from https://www.figma.com/file/GpbLNhQGrYKCTFO8aZy8BK/Hotspot-bug
  2. Click the gray bottom rectangle with or without scrolling
  3. It wrongly triggers the hotspot from the “background” items
    Pinned Reply By djv

    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. 

    54 replies

    Show previous 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