Repository navigation
fix(Tooltip, overlays): hide on close even when the closed render lands late on Server (#608) - #609
Merged
Merged
Conversation
…ds late on Server (#608) overlay.close reaches the browser ahead of the render that writes data-state="closed", up to a round trip ahead when the portal host is still waiting on its previous batch. hidePosition read data-state to tell a reopen from a close, saw "open", and skipped the hide, leaving the overlay on screen. overlay.close now passes its own token check, so only a real reopen (which takes a new token) cancels the hide. Direct hidePosition callers keep the data-state check.
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
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.
Fixes #608.
Cause.
overlay.closeis dispatched fromOnParametersSet, so it reaches the browser ahead of the render that writesdata-state="closed". When the portal host is still waiting on the browser to acknowledge its previous batch (for example the open render, just before a quick mouse leave), the closed render is deferred a full round trip.hidePositionreaddata-stateafter one frame to tell a reopen from a close, saw"open", and returned without hiding. The inlinevisibility: visible !important; opacity: 1 !importantfrom the open stayed.Fix.
hidePositiontakes an optional reopen check.overlay.closepasses its own token check, so only a real reopen (overlay.opentakes a new token) cancels the hide. DirecthidePositioncallers (IPositioningService.HidePositionAsync) keep thedata-statecheck. No public API change.Tests. New
tests/js/overlay-close.test.mjsruns the realoverlay.closeandhidePosition:data-statestill saidclosed)Server demo, with 100 ms added each way between the browser and the circuit (Chrome,
DelayDuration="0"tooltip on/primitives/tooltip):data-state="closed"with the inline visible stylesThe issue's own repro (6x CPU slowdown, no added delay) did not reproduce locally: 0 of 30. Latency is what triggers it here.
Note. When the close lands before the closed render, the exit animation has not started yet, so the overlay hides without its fade. Before this fix it stuck on screen in that case.
Type of Change
Testing Checklist