Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instant preview misplacement with tabs above #6735

Closed
4 tasks done
pawamoy opened this issue Feb 3, 2024 · 2 comments
Closed
4 tasks done

Instant preview misplacement with tabs above #6735

pawamoy opened this issue Feb 3, 2024 · 2 comments
Labels
bug Issue reports a bug resolved Issue is resolved, yet unreleased if open

Comments

@pawamoy
Copy link
Sponsor Contributor

pawamoy commented Feb 3, 2024

Context

Reported here first: #6704 (comment).

Bug description

Instant previews enabled globally with navigation.instant.preview.

When there are tabs above a previewable link, the preview windows can be misplaced: it seems the preview windows position are calculated once, when the page loads. If I change tabs above previewable links, and these tabs have different heights, then all previewable links after these tabs have misplaced preview windows. If I reload the page, staying on the second tab, positions are recalculated correctly. Well, these are assumptions, you'll know better what's really happening 🙂

Related links

Reproduction

9.5.7+insiders.4.52.1-instant-preview-misplacement.zip

Steps to reproduce

  • Serve the given reproduction and go to the home page.
  • Assert both previewable links have correct preview window positions.
  • Now change to second tab in the "Tabs before" section.
  • Assert that first link preview is still correct, but second link preview isn't. Increase or reduce space below second link (by scrolling) to see both behaviors (when there's enough space below the link to show the preview window, or not).

Browser

Firefox

Before submitting

@squidfunk squidfunk added the bug Issue reports a bug label Feb 4, 2024
@squidfunk
Copy link
Owner

Fixed in b4b1a42. So, we forgot to recompute the absolute element offset after the tooltip was activated for the first time. This should now be fixed with the latest commit, albeit we didn't yet find the best method of accurately tracking element offsets. We'll definitely do a small refactoring once we could smooth the rough edges of the new tooltips implementation, but for the time being, the issue should be resolved ☺️

@squidfunk squidfunk added the resolved Issue is resolved, yet unreleased if open label Feb 4, 2024
@squidfunk
Copy link
Owner

Released as part of 9.5.8+insiders-4.52.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue reports a bug resolved Issue is resolved, yet unreleased if open
Projects
None yet
Development

No branches or pull requests

2 participants