[GH-ISSUE #18972] Share chat link: clipboard copy fails silently #18732

New Issue

GiteaMirror · 2026-04-20T00:56:15-05:00

GiteaMirror commented

2026-04-20 00:56:15 -05:00

Originally created by @lski-tools on GitHub (Nov 6, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18972

Description:

When clicking "Update and Copy Link" (or "Copy Link" for new shares), the link gets created successfully but copying to clipboard fails. The success message still appears, which is misleading since nothing was actually copied.

Relevant line in code
e85c7f7931/src/lib/components/chat/ShareChatModal.svelte (L173)

Environment:

Firefox 140.4.0esr (64-Bit)
Open WebUI version: [latest from main branch]

I can work around this by clicking the share button again after creation, which shows the link that I can then click to open it. But the copy to clipboard functionality doesn't work.

Expected behavior:
Link should be copied to clipboard

Actual behavior:

Link is created (confirmed by re-opening share dialog)
Success toast appears
Clipboard remains empty

Root cause:

Looking at src/lib/components/chat/ShareChatModal.svelte, the non-Safari code path does this:

copyToClipboard(await shareLocalChat());
toast.success($i18n.t('Copied shared chat URL to clipboard!'));
show = false;

Two problems here:

No error handling on the copyToClipboard() call
Success message shows regardless of whether copy worked

Suggested fix:

Adding error handling would help, but a fallback would be better since clipboard access can fail for various reasons (permissions, browser policies, etc).

Simple example:

const url = await shareLocalChat();
try {
    await navigator.clipboard.writeText(url);
    toast.success($i18n.t('Copied shared chat URL to clipboard!'));
} catch (error) {
    // Fallback: show the URL so user can copy manually
    shareUrl = url;
    toast.info($i18n.t('Link created. Click to copy manually.'));
}

Then display shareUrl in the modal if it's set, with a button to copy it.

This way users always have a way to get the link, even if automatic clipboard access fails.

Originally created by @lski-tools on GitHub (Nov 6, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18972 **Description:** When clicking "Update and Copy Link" (or "Copy Link" for new shares), the link gets created successfully but copying to clipboard fails. The success message still appears, which is misleading since nothing was actually copied. **Relevant line in code** https://github.com/open-webui/open-webui/blob/e85c7f79310f351672fe967a102396b6f3f5e88b/src/lib/components/chat/ShareChatModal.svelte#L173 **Environment:** - Firefox 140.4.0esr (64-Bit) - Open WebUI version: [latest from main branch] I can work around this by clicking the share button again after creation, which shows the link that I can then click to open it. But the copy to clipboard functionality doesn't work. **Expected behavior:** Link should be copied to clipboard **Actual behavior:** - Link is created (confirmed by re-opening share dialog) - Success toast appears - Clipboard remains empty **Root cause:** Looking at `src/lib/components/chat/ShareChatModal.svelte`, the non-Safari code path does this: ```javascript copyToClipboard(await shareLocalChat()); toast.success($i18n.t('Copied shared chat URL to clipboard!')); show = false; ``` Two problems here: 1. No error handling on the `copyToClipboard()` call 2. Success message shows regardless of whether copy worked **Suggested fix:** Adding error handling would help, but a fallback would be better since clipboard access can fail for various reasons (permissions, browser policies, etc). Simple example: ```javascript const url = await shareLocalChat(); try { await navigator.clipboard.writeText(url); toast.success($i18n.t('Copied shared chat URL to clipboard!')); } catch (error) { // Fallback: show the URL so user can copy manually shareUrl = url; toast.info($i18n.t('Link created. Click to copy manually.')); } ``` Then display `shareUrl` in the modal if it's set, with a button to copy it. This way users always have a way to get the link, even if automatic clipboard access fails.

GiteaMirror closed this issue

2026-04-20 00:56:16 -05:00

GiteaMirror commented

2026-04-20 00:56:16 -05:00

@silentoplayz commented on GitHub (Nov 6, 2025):

You're correct and I am able to confirm this issue. Either copying fails with Update and Copy Link or it is failing to delete the old share link, generate a new one, and copy the newly generated share link to the clipboard.

Current behavior: The user needs to manually click on the delete this link text, followed by clicking the Copy Link button again to delete the old share link for the chat, generate a new one, and copy the newly generated share link to the clipboard.

Expected behavior: For the Update and Copy Link button to perform the behavior of what clicking on the delete this link text, followed by clicking the Copy Link button does. Or in short, for it to work as expected.

@silentoplayz commented on GitHub (Nov 6, 2025): You're correct and I am able to confirm this issue. Either copying fails with `Update and Copy Link` or it is failing to delete the old share link, generate a new one, and copy the newly generated share link to the clipboard. Current behavior: The user needs to manually click on the `delete this link` text, followed by clicking the `Copy Link` button again to delete the old share link for the chat, generate a new one, and copy the newly generated share link to the clipboard. Expected behavior: For the `Update and Copy Link` button to perform the behavior of what clicking on the `delete this link` text, followed by clicking the `Copy Link` button does. Or in short, for it to work as expected.

GiteaMirror commented

2026-04-20 00:56:17 -05:00

@tjbck commented on GitHub (Nov 6, 2025):

is this FF only? @silentoplayz I'm unable to reproduce.

@tjbck commented on GitHub (Nov 6, 2025): is this FF only? @silentoplayz I'm unable to reproduce.

GiteaMirror referenced this issue

2026-04-25 08:07:31 -05:00

[GH-ISSUE #18732] issue: Global Tool Servers doesn't show full list of functions #34218

GiteaMirror referenced this issue

2026-05-05 20:53:04 -05:00

[GH-ISSUE #18732] issue: Global Tool Servers doesn't show full list of functions #57355

Sign in to join this conversation.