Lexical version: 0.44(latest) (tested on https://playground.lexical.dev)
Two related issues observed only on Safari (macOS) when interacting with image links via FloatingLinkEditor. Both reproduce with the official playground.
Issue 1: URL input is mispositioned when adding a link to an image
Steps To Reproduce
- Open the playground in Safari.
- Insert an image and click it to select.
- Click the link button in the toolbar (or press Cmd/Ctrl+K) to open the URL input.
The current behavior
The URL input box overlaps the image (around its vertical middle) instead of being positioned below or above. The input covers the image content while the user is typing.
This happens before the link is committed — at the moment the URL input first appears (no LinkNode exists in the editor model yet). Chrome and Firefox position the input correctly below the image.
The expected behavior
The URL input should appear below the image (or above when there isn't room below).
Issue 2: Image briefly disappears when the popup mounts/unmounts
Steps To Reproduce
- Open the playground in Safari.
- Insert an image and add a link to it.
- Click the link button or the trash icon to open/close the FloatingLinkEditor popup.
- Watch the image while the popup mounts/unmounts.
The current behavior
The image briefly disappears (single-frame flicker) when the FloatingLinkEditor popup is mounted or unmounted. The image returns immediately but the flicker is noticeable.
Chrome and Firefox do not exhibit this behavior.
The expected behavior
The image should remain visible during popup mount/unmount.
Notes
The image is rendered as a Lexical DecoratorNode (React-managed). The FloatingLinkEditor popup is rendered via createPortal with position: absolute (@floating-ui/react). Both issues likely share a root cause related to WebKit's reconciliation/layout timing for portal-mounted absolutely-positioned elements adjacent to React-managed decorator content.
PR #8419 addresses related FloatingLinkEditor mispositioning for multi-line and decorator-only links, but the symptoms above happen specifically on Safari before the LinkNode is materialized (Issue 1) or during portal mount/unmount (Issue 2), neither of which is covered by that PR's RangeSelection-branch fix.
Lexical version: 0.44(latest) (tested on https://playground.lexical.dev)
Two related issues observed only on Safari (macOS) when interacting with image links via FloatingLinkEditor. Both reproduce with the official playground.
Issue 1: URL input is mispositioned when adding a link to an image
Steps To Reproduce
The current behavior
The URL input box overlaps the image (around its vertical middle) instead of being positioned below or above. The input covers the image content while the user is typing.
This happens before the link is committed — at the moment the URL input first appears (no LinkNode exists in the editor model yet). Chrome and Firefox position the input correctly below the image.
The expected behavior
The URL input should appear below the image (or above when there isn't room below).
Issue 2: Image briefly disappears when the popup mounts/unmounts
Steps To Reproduce
The current behavior
The image briefly disappears (single-frame flicker) when the FloatingLinkEditor popup is mounted or unmounted. The image returns immediately but the flicker is noticeable.
Chrome and Firefox do not exhibit this behavior.
The expected behavior
The image should remain visible during popup mount/unmount.
Notes
The image is rendered as a Lexical DecoratorNode (React-managed). The FloatingLinkEditor popup is rendered via
createPortalwithposition: absolute(@floating-ui/react). Both issues likely share a root cause related to WebKit's reconciliation/layout timing for portal-mounted absolutely-positioned elements adjacent to React-managed decorator content.PR #8419 addresses related FloatingLinkEditor mispositioning for multi-line and decorator-only links, but the symptoms above happen specifically on Safari before the LinkNode is materialized (Issue 1) or during portal mount/unmount (Issue 2), neither of which is covered by that PR's RangeSelection-branch fix.