[lexical-playground] Bug Fix: Position FloatingLinkEditor below the entire link for multi-line and decorator-only links#8419
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| if (linkElement) { | ||
| const rects = linkElement.getClientRects(); | ||
| domRect = | ||
| rects[rects.length - 1] || |
There was a problem hiding this comment.
It looks like floating-ui has a better solution for this sort of situation. https://floating-ui.com/docs/inline
There was a problem hiding this comment.
Thanks for pointing to inline! I tried it and ran into an issue I couldn't resolve cleanly.
After applying inline, the toolbar lands at different visual positions across attempts even when the reference is the same.
Attempt A:
Attempt B:
Hello(link: www.google-)
Bye(link: www.naver-)
Both attempts log the same reference:
- text:
bye - rect:
{top: 298.27, left: 28, width: 98.33, height: 17.5}
Same reference, identical rect, different rendered position. The same pattern reproduces with another link in the document. Calling update() explicitly after setReference() did not change the outcome.
For this PR, I kept the single bounding rect approach (linkElement.getBoundingClientRect()) since the issue doesn't reproduce there.
The behavior with inline looks like it needs a deeper look — would you prefer to investigate it in this PR, or split it into a separate issue and look into it there? Happy to either way.
There was a problem hiding this comment.
Slight preference to try and resolve all known positioning issues with the floating link toolbar in this PR, but up to you
There was a problem hiding this comment.
Dug into this more — turned out it's how setReference(domElement) interacts with inline, not inline itself. Swapped it for setPositionReference with a virtual element exposing both rect methods, and the positioning issues went away. Updating the PR.
There was a problem hiding this comment.
Pushed the change. Switched to setPositionReference with a virtual element exposing both getBoundingClientRect() and getClientRects(), and inline is now in the middleware chain. Verified the previously broken cases (viewport-bottom flip, mouse vs keyboard entry, sticky placement) all behave correctly with this approach.
7058e4e to
ce8aaf8
Compare
…ast line of multi-line links For multi-line links, the toolbar attached to the cursor's range rect (one line tall), so a cursor on line 1 placed the toolbar between line 1 and line 2 — covering line 2. Use the link element's last client rect (the last visual line of the link) as the reference for floating-ui so the toolbar always sits below the entire link. Falls back to the range rect when the cursor is not inside a link. Fixes facebook#8263
ce8aaf8 to
3ef66c6
Compare
etrepum
left a comment
There was a problem hiding this comment.
Looks great for the cases I tried!
Summary
getClientRects()[last](the last visual line of the link). Falls back to the prior range-rect behavior when the cursor is not inside a link.<a>rect sit on the image's lower half). When the link has a single decorator child, anchor to the decorator's rect directly so the toolbar lands below the image.Before
After
Test plan
$getSelectedLinkNode's right-bias path