@linktr.ee/messaging-react 3.31.0-rc-1785485102 → 3.31.0

package/src/components/CustomMessageInput/CustomMessageInput.test.tsx

@@ -37,12 +37,21 @@ vi.mock('stream-chat-react', () => ({
       <Input />
     </div>
   ),
+  // `maxRows` is surfaced as a data attribute rather than spread onto the
+  // <textarea> (which React would warn about) so a test can still assert it —
+  // stripping it silently would hide the clamp that MES-1037 removed.
   TextareaComposer: ({
-    maxRows: _maxRows,
+    maxRows,
     ...props
   }: React.TextareaHTMLAttributes<HTMLTextAreaElement> & {
     maxRows?: number
-  }) => <textarea data-testid="textarea-composer" {...props} />,
+  }) => (
+    <textarea
+      data-testid="textarea-composer"
+      data-max-rows={String(maxRows)}
+      {...props}
+    />
+  ),
   AttachmentPreviewList: () => <div data-testid="attachment-preview-list" />,
   QuotedMessagePreview: () => <div data-testid="quoted-message-preview" />,
   useChannelStateContext: () => ({
@@ -318,6 +327,175 @@ describe('CustomMessageInput', () => {
     expect(screen.getByTestId('stream-message-input')).toBeInTheDocument()
   })
 
+  // MES-1037: a staged link preview made the composer tall enough for the soft
+  // keyboard to cover the textarea and the send button. The card now caps itself
+  // against the keyboard-shrunk surface and scrolls as one region.
+  //
+  // None of the *layout* can be verified here — jsdom has no layout engine, so
+  // no sticky, no overflow, and the polyfilled ResizeObserver measures
+  // getBoundingClientRect, which jsdom always reports as zero. These are
+  // regression guards on the classes and the observer's behaviour; the layout
+  // itself was verified in real Chrome over the DevTools protocol.
+  describe('keeps the composer clear of the soft keyboard (MES-1037)', () => {
+    let resizeCard: (() => void) | undefined
+
+    beforeEach(() => {
+      mockChannelData = {}
+      resizeCard = undefined
+      vi.stubGlobal(
+        'ResizeObserver',
+        class {
+          constructor(cb: ResizeObserverCallback) {
+            resizeCard = () => cb([], this as unknown as ResizeObserver)
+          }
+          observe() {}
+          unobserve() {}
+          disconnect() {}
+        }
+      )
+    })
+
+    afterEach(() => {
+      vi.unstubAllGlobals()
+    })
+
+    const renderCard = () => {
+      const { container } = renderWithProviders(<CustomMessageInput />)
+      return container.querySelector('.central-container') as HTMLElement
+    }
+
+    it('caps the card against the surface height and scrolls it as one region', () => {
+      const card = renderCard()
+
+      expect(card).toHaveClass(
+        'max-h-[calc(var(--messaging-surface-height,100dvh)*0.5)]',
+        'overflow-y-auto',
+        'overscroll-contain'
+      )
+      // Nothing inside may shrink, or the previews get cropped to make room for
+      // the textarea instead of scrolling with it.
+      expect(card).not.toHaveClass('min-h-0')
+      expect(card.querySelector('.messaging-composer-previews')).not.toHaveClass(
+        'min-h-0'
+      )
+      expect(card.querySelector('.messaging-composer-row')).not.toHaveClass(
+        'shrink-0'
+      )
+    })
+
+    it('lets the textarea grow to fit rather than scrolling its own overflow', () => {
+      const card = renderCard()
+
+      // TextareaComposer defaults an absent maxRows to 1, so this has to be set.
+      expect(screen.getByTestId('textarea-composer')).toHaveAttribute(
+        'data-max-rows',
+        'Infinity'
+      )
+      // Growing to fit is what keeps it from overflowing; overflow-hidden is
+      // what keeps it from becoming a second scrollbar on the occasions the
+      // autosize is momentarily out of date (a width change it never hears
+      // about, e.g. the card gaining its own scrollbar and rewrapping the text).
+      expect(screen.getByTestId('textarea-composer')).toHaveClass(
+        'overflow-hidden'
+      )
+      // And the card stays the one region that does scroll.
+      expect(card).toHaveClass('overflow-y-auto')
+    })
+
+    it('leaves plain-text pastes to the browser but lets file pastes reach Stream', () => {
+      renderCard()
+
+      // Stream's paste handler is dispatched from React's root, above this
+      // card, so a listener further up stands in for it: the event reaching
+      // there means Stream would have handled it (and preventDefault'd the
+      // browser's own insert, which is what leaves the composer unresized).
+      const reachedStream = vi.fn()
+      document.addEventListener('paste', reachedStream)
+
+      const paste = (items: Array<{ kind: string }>) => {
+        const event = new Event('paste', { bubbles: true, cancelable: true })
+        Object.defineProperty(event, 'clipboardData', { value: { items } })
+        screen.getByTestId('textarea-composer').dispatchEvent(event)
+      }
+
+      paste([{ kind: 'string' }])
+      expect(reachedStream).not.toHaveBeenCalled()
+
+      paste([{ kind: 'file' }])
+      expect(reachedStream).toHaveBeenCalledTimes(1)
+
+      document.removeEventListener('paste', reachedStream)
+    })
+
+    it('detects a pasted file via clipboardData.items even when .files is empty (Safari)', () => {
+      renderCard()
+
+      // Safari never populates clipboardData.files on paste, even for an
+      // image — only .items has it. Checking .files here would silently drop
+      // a pasted screenshot instead of handing it to Stream to upload.
+      const reachedStream = vi.fn()
+      document.addEventListener('paste', reachedStream)
+
+      const event = new Event('paste', { bubbles: true, cancelable: true })
+      Object.defineProperty(event, 'clipboardData', {
+        value: { files: [], items: [{ kind: 'file' }] },
+      })
+      screen.getByTestId('textarea-composer').dispatchEvent(event)
+
+      expect(reachedStream).toHaveBeenCalledTimes(1)
+
+      document.removeEventListener('paste', reachedStream)
+    })
+
+    it('scrolls the input back into view when the card shrinks under it', () => {
+      const card = renderCard()
+      // jsdom has no layout, so stand in for a card whose cap now cuts the
+      // input off below the fold.
+      Object.defineProperty(card, 'scrollHeight', {
+        configurable: true,
+        value: 380,
+      })
+      screen.getByTestId('textarea-composer').focus()
+
+      resizeCard?.()
+
+      expect(card.scrollTop).toBe(380)
+    })
+
+    it('leaves the scroll position alone when nothing in the composer is focused', () => {
+      const card = renderCard()
+      Object.defineProperty(card, 'scrollHeight', {
+        configurable: true,
+        value: 380,
+      })
+      // The composer autofocuses, so blur to reach the case this guards: a
+      // resize with no keyboard up must not yank a visitor reading a preview.
+      screen.getByTestId('textarea-composer').blur()
+
+      resizeCard?.()
+
+      expect(card.scrollTop).toBe(0)
+    })
+
+    it('sticks the send button to the bottom of the scroll, at its resting inset', () => {
+      renderCard()
+
+      // The offset must match the wrapper's own margin: sticky resolves against
+      // the border box, so at bottom-0 the button would lose that inset and sit
+      // flush with the card's edge for as long as it stayed stuck. pt-2 gives
+      // the same inset above: sticky offsets only the bottom edge, so once the
+      // card scrolls far enough for the button to ride up to the top of the
+      // row, a staged preview otherwise meets it flush. Asserted together so
+      // they cannot drift apart.
+      expect(screen.getByTestId('send-button').parentElement).toHaveClass(
+        'sticky',
+        'bottom-2',
+        'mb-2',
+        'pt-2'
+      )
+    })
+  })
+
   // MES-1303: the floating composer overlays the message list, so growing it
   // reserves space via padding-bottom but never moves the viewport. The resize
   // observer re-pins the thread to the latest message when the composer grows —

package/src/components/CustomMessageInput/index.tsx

@@ -79,15 +79,96 @@ const CustomMessageInputInner: React.FC = () => {
     AttachmentPreviewList = DefaultAttachmentPreviewList,
   } = useComponentContext('CustomMessageInput')
 
+  // Scroll the textarea back into view when the card shrinks under it. Browsers
+  // reveal a newly focused element by themselves, and the caret while typing, so
+  // neither needs help; the one thing nothing reveals is the box getting shorter
+  // underneath the input — which is exactly what the keyboard does here, a beat
+  // after the tap that raised it, once the host reports it and the cap below
+  // follows the shrunken surface (MES-1037).
+  const cardRef = React.useRef<HTMLDivElement>(null)
+  React.useEffect(() => {
+    const card = cardRef.current
+
+    if (!card || typeof ResizeObserver === 'undefined') {
+      return
+    }
+
+    const observer = new ResizeObserver(() => {
+      if (card.contains(document.activeElement)) {
+        card.scrollTop = card.scrollHeight
+      }
+    })
+    observer.observe(card)
+
+    return () => observer.disconnect()
+  }, [])
+
+  // Let the browser insert pasted text itself, so the composer grows to fit it
+  // immediately (MES-1037). Stream's paste handler calls preventDefault and
+  // feeds the text back through composer state asynchronously; TextareaComposer
+  // then assigns `textarea.value` in a layout effect, which fires no input event
+  // and so never triggers react-textarea-autosize's re-measure — leaving the
+  // composer one line tall, with the pasted text hidden, until the next
+  // keystroke happens to resize it. Letting the default action run puts pasted
+  // text on exactly the path typed text takes, which measures correctly.
+  //
+  // It has to be a native listener that stops propagation rather than an
+  // `onPaste` prop: TextareaComposer takes `onPaste` from the message-input
+  // context and applies it after spreading our props, so ours would be
+  // overridden, and a React handler on this card would run after the textarea's
+  // anyway. Stopping the event here keeps it from reaching React's root, where
+  // Stream's handler is dispatched from. Pastes carrying a file still go to
+  // Stream, which uploads it as an attachment.
+  React.useEffect(() => {
+    const card = cardRef.current
+
+    if (!card) {
+      return
+    }
+
+    const passToBrowser = (event: ClipboardEvent) => {
+      // `items`, not `files`: Safari never populates `clipboardData.files` on
+      // paste, even for an image, only `items` — which is why Stream's own
+      // handler reads files via `items` (`dataTransferItemsToFiles`) rather
+      // than `.files`. Checking `.files.length` here would treat a pasted
+      // screenshot as plain text on Safari and drop it silently instead of
+      // handing it to Stream to upload.
+      const hasFile = Array.from(event.clipboardData?.items ?? []).some(
+        (item) => item.kind === 'file'
+      )
+      if (!hasFile) {
+        event.stopPropagation()
+      }
+    }
+
+    card.addEventListener('paste', passToBrowser)
+
+    return () => card.removeEventListener('paste', passToBrowser)
+  }, [])
+
   return (
-    // min-h-0 lets the composer shrink under keyboard squeeze (the link
-    // preview list inside is the scrollable region); the textarea + send row
-    // is shrink-0 so it can never be pushed out of view. self-stretch matters
-    // because the parent `.message-input` row uses items-end, which suppresses
-    // the default cross-axis stretch — without it this container keeps its
-    // content height and the squeeze never reaches the preview list. Stream's
-    // <MessageInput> renders its Input directly (context providers only, no
-    // wrapper element), so this is a direct flex item of that row.
+    // This card is the composer's ONE scroll container: staged previews and the
+    // textarea row scroll together past a cap, instead of the previews being
+    // squeezed to keep the row in view (MES-1037). Nothing inside may shrink, or
+    // the previews get cropped rather than scrolled — hence no `min-h-0` here or
+    // on the previews wrapper, no `shrink-0` on the row, and no nested scroller
+    // in CustomLinkPreviewList. Every child keeps its intrinsic height and the
+    // overflow lands on this scrollport. `self-stretch` went with the squeeze it
+    // fed: the parent `.message-input` row is `items-end`, so the card now sizes
+    // to its content up to the cap. Stream's <MessageInput> renders its Input
+    // directly (context providers only, no wrapper element), so this is a direct
+    // flex item of that row.
+    //
+    // The cap is half the *keyboard-shrunk* surface height, because a cap that
+    // doesn't shrink with the keyboard lets the card spill past the visible
+    // viewport — which is the bug. No CSS unit tracks the visual viewport, so
+    // `--messaging-surface-height` is an optional host contract, like this
+    // package's own `--messaging-composer-height`: linktr.ee-profiles publishes
+    // it on the messaging surface (an ancestor of this composer at runtime) from
+    // its own `visualViewport` measurement, and it inherits in. Hosts that don't
+    // fall back to `100dvh` — bounded, but not keyboard-aware. Deliberately not
+    // measured here: the host owns viewport control and the package must not
+    // fight it for it.
     //
     // The container itself carries no padding of its own: it used to (p-2),
     // but that inset now lives on the textarea as padding instead, so the
@@ -102,18 +183,22 @@ const CustomMessageInputInner: React.FC = () => {
     // `[&>:not(...)]:p-2` variant restores the container's old inset for any
     // such foreign direct child, without re-adding it to our own wrappers.
     <div
-      className="central-container flex min-h-0 flex-col min-w-0 w-full self-stretch bg-white rounded-[1.5rem] shadow-[0_4px_16px_0_rgba(0,0,0,0.08),0_1px_2px_0_rgba(0,0,0,0.04),0_0_0_1px_rgba(0,0,0,0.04)] [&>:not(.messaging-composer-previews):not(.messaging-composer-row)]:p-2"
+      ref={cardRef}
+      className="central-container flex flex-col min-w-0 w-full max-h-[calc(var(--messaging-surface-height,100dvh)*0.5)] overflow-y-auto overscroll-contain bg-white rounded-[1.5rem] shadow-[0_4px_16px_0_rgba(0,0,0,0.08),0_1px_2px_0_rgba(0,0,0,0.04),0_0_0_1px_rgba(0,0,0,0.04)] [&>:not(.messaging-composer-previews):not(.messaging-composer-row)]:p-2"
       data-dd-privacy="mask"
     >
       {/* empty:hidden collapses this row (padding, gap, and all) when none of
           the previews below have anything to render, so an idle composer has
-          no leftover top inset before the textarea row. */}
-      <div className="messaging-composer-previews empty:hidden flex min-h-0 flex-col gap-2 px-2 pt-2">
+          no leftover top inset before the textarea row. No bottom inset: the
+          textarea's own py-3.5 already separates the last preview from the
+          text, and adding one here double-spaces them now that both sit in the
+          same scroll. */}
+      <div className="messaging-composer-previews empty:hidden flex flex-col gap-2 px-2 pt-2">
         <QuotedMessagePreview />
         <CustomLinkPreviewList />
         <AttachmentPreviewList />
       </div>
-      <div className="messaging-composer-row flex shrink-0 items-start">
+      <div className="messaging-composer-row flex items-start">
         <TextareaComposer
           aria-disabled={disabled || undefined}
           // TextareaComposer wraps the real <textarea> in its own div, so
@@ -125,7 +210,19 @@ const CustomMessageInputInner: React.FC = () => {
           containerClassName="min-w-0 flex-1 leading-[0]"
           // bg-transparent: the container has no padding to inset it behind
           // anymore, so an opaque textarea would paint over its rounded corners.
-          className="w-full resize-none bg-transparent py-3.5 pl-4 pr-4 outline-none leading-5 placeholder:text-black/30 text-sm"
+          //
+          // overflow-hidden makes "the card is the only scrollable region" a
+          // property of the CSS rather than of the autosize arithmetic always
+          // landing exactly right. A textarea's UA default is `overflow: auto`,
+          // and TextareaComposer sizes itself by copying the computed style into
+          // a detached measuring textarea on input, window resize and font load
+          // only — so any width change it does not hear about (most obviously
+          // this card gaining its own scrollbar, which narrows the textarea and
+          // rewraps the text onto another line) leaves it a line short and
+          // sprouts a second scrollbar inside the first. The caret stays visible
+          // either way: browsers still scroll an overflow-hidden textarea to
+          // reveal it, and the next keystroke re-fits the height.
+          className="w-full resize-none overflow-hidden bg-transparent py-3.5 pl-4 pr-4 outline-none leading-5 placeholder:text-black/30 text-sm"
           // While this might usually be considered an anti-pattern, in most
           // cases, when a message thread is rendered, we want the input to
           // gain focus automatically.
@@ -134,7 +231,12 @@ const CustomMessageInputInner: React.FC = () => {
           // Enter sends (Shift+Enter inserts a newline), so label the
           // on-screen keyboard's return key accordingly.
           enterKeyHint="send"
-          maxRows={4}
+          // Grow to fit every line rather than scrolling the overflow inside
+          // the textarea past a few of them: the card above is the one scroll
+          // container, so a message long enough to outgrow it scrolls there, as
+          // one piece with the previews. Explicit because TextareaComposer
+          // defaults an absent `maxRows` to 1, not to "no cap".
+          maxRows={Infinity}
           readOnly={disabled}
           tabIndex={disabled ? -1 : undefined}
         />
@@ -143,8 +245,33 @@ const CustomMessageInputInner: React.FC = () => {
             grows — lives on a wrapper instead of the button's own
             className: a host-supplied SendButton can (and, per our own
             stories, does) spread its own className over the one we pass in,
-            which would otherwise silently drop this spacing. */}
-        <div className="mt-auto mb-2 mr-2 shrink-0">
+            which would otherwise silently drop this spacing. The sticky is
+            here for the same reason.
+
+            sticky: mt-auto alone anchors the button to the bottom of a row the
+            textarea can grow taller than the card, carrying send out of the
+            scroll's view while you are still typing. Sticking it to the
+            scrollport keeps it reachable without a scroll, floating over the
+            textarea's own column, so nothing reflows and no text runs under it.
+            The offset matches mb-2 because sticky resolves against the border
+            box, not the margin box: at bottom-0 the button would drop that
+            inset and sit flush with the card's edge for as long as it stayed
+            stuck. A sticky element cannot leave its containing block, which is
+            the row — so scrolling all the way up to the previews takes the
+            button off-screen with the row it belongs to, and it is pinned at
+            every position where the row is in view, i.e. whenever you are
+            typing.
+
+            pt-2 gives the button the same inset above it that mb-2 gives below,
+            and keeps it there while the card scrolls: sticky offsets only the
+            bottom edge, so once the card scrolls far enough for the button to
+            ride up to the top of the row, a staged preview would otherwise meet
+            it flush. The padding travels with the button, so the gap holds at
+            every scroll position rather than only at rest. It needs no
+            background to sit on: sticky cannot leave its containing block, so
+            the button stays inside the row and a preview never passes behind
+            it. */}
+        <div className="sticky bottom-2 mt-auto mb-2 mr-2 shrink-0 pt-2">
           <SendButton
             sendMessage={handleSubmit}
             aria-label="Send"