fix(webchat): keep embedding origin stable across rerenders

[baokimho]

What

Embedded webchat text messages could start sending the iframe's own origin after a rerender instead of the embedding site's origin.

Subsequent messages were then rejected with:

This website is not authorized to load this chat widget.

Root cause

WebchatMessageInput used the server-derived parentOrigin in its form defaults. After a rerender with the iframe origin, reset(defaultValues) could replace the original embedding-site origin, causing later submissions to mismatch the access token's originHost.

Fix

• Resolve the client embedding origin once with getClientEmbeddingOrigin()
• Keep that origin stable across later rerenders
• Use the stable origin for form defaults/resets
• Pass the same stable origin to message-menu actions
• Preserve the server-provided origin as the initial fallback

Authorization and authorized-domain validation remain unchanged.

Tests

Added a regression test covering:

parent origin → rerender with iframe origin → first submit → reset → second submit

Both submissions retain the original embedding-site origin.

git diff --check passes. The focused Vitest test could not run locally because of a Windows EPERM environment issue; CI should validate it.

Fixes #1166

[Copilot]

🟡 Changes recommended

The critical origin mismatch can reject all messages when Referer is absent.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Fixes webchat message rejection after rerenders by preserving the client-resolved embedding origin.

Changes:

• Stabilizes the origin for message submissions and menu actions.
• Adds regression coverage across rerenders and form resets.

File summaries

File	Summary
apps/builder/src/features/integration-webchat/webchat-message-input.tsx	Preserves the embedding origin. Critical (1 vote): a null server origin can mismatch token minting when Referer is absent.
apps/builder/__tests__/webchat-message-input-origin.test.tsx	Tests origin persistence. Nit (1 vote): the mock does not derive the second request from reset state.

Review details

Suppressed comments (1)

apps/builder/tests/webchat-message-input-origin.test.tsx:38

• This mock submitter builds every request from mocks.defaultValues, which is overwritten on each render, while form.reset is only a no-op spy. Consequently the second submit never reads the form state produced by reset(defaultValues), so a regression in the reset path could still pass this test. Track the mock form values (and update them from reset) or assert the reset argument and derive the second request from that state.

    const submit = async () => {
      const input = {
        ...mocks.defaultValues,
        text: "hello",
      }

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[baokimho]

Addressed in the latest commit. Null server origins now remain null, and the regression test now tracks reset form state.