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.
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.
