initialize visibility on re-slotted/re-attached hotspot elements#5161
Merged
Conversation
When a hotspot's light DOM element is shifted in the children list (e.g., because another hotspot is deleted in a reactive UI loop), the browser detaches and re-attaches (re-slots) the element. While the core AnnotationMixin correctly reuses the existing Three.js Hotspot instance and increments its reference count, the newly attached DOM button element never receives the current visibility attributes (such as `data-visible`) because the hotspot's general visibility state has not transitioned. This leaves the re-slotted buttons in a hollow, invisible, or un-annotated state depending on CSS selectors matching :not([data-visible]). This patch updates the addHotspot path in the AnnotationMixin to immediately set the visibility attribute and dispatch the target `hotspot-visibility` custom event on the incoming node when its associated Hotspot object already exists. This guarantees that re-slotted elements inherit and render with the correct Three.js visibility states instantly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a hotspot's light DOM element is shifted in the children list (e.g., because another hotspot is deleted in a reactive UI loop), the browser detaches and re-attaches (re-slots) the element. While the core AnnotationMixin correctly reuses the existing Three.js Hotspot instance and increments its reference count, the newly attached DOM button element never receives the current visibility attributes (such as
data-visible) because the hotspot's general visibility state has not transitioned. This leaves the re-slotted buttons in a hollow, invisible, or un-annotated state depending on CSS selectors matching :not([data-visible]). This patch updates the addHotspot path in the AnnotationMixin to immediately set the visibility attribute and dispatch the targethotspot-visibilitycustom event on the incoming node when its associated Hotspot object already exists. This guarantees that re-slotted elements inherit and render with the correct Three.js visibility states instantly.Reference Issue