openclaw - 💡(How to fix) Fix [Feature]: Webchat Control UI — Add quote/reply button to message bubbles

Summary

Summary

Request to add a "Quote/Reply" button to message bubbles in the Webchat Control UI, allowing users to reply to specific messages.

The backend protocol already supports this via and directives (parsed in dist/control-ui/assets/index-B5x_BDbc.js), but there is no UI button to trigger this action — users must type the directive manually.

---

Problem

Current State

• ✅ Backend support exists: The reply payload system supports m.in_reply_to protocol
• ✅ Directive parsing exists: Control UI JS already parses and tags
• ❌ No UI trigger: Message bubbles have no "Quote" button to initiate a reply
• ❌ No visual indicator: When replying, there's no preview showing which message is being quoted

User Impact

Users cannot easily reply to specific messages in a conversation thread. This is a basic chat feature available in:

• Telegram (reply/swipe)
• WhatsApp (quote button)
• Slack/Discord (reply thread)
• Feishu (quote reply)

---

Proposed Solution

UI Changes

1. Add "Quote" button to message bubble action bar

   • Position: Alongside existing buttons (copy, reactions, etc.)
   • Icon: ↩️ or standard quote icon
   • Hover tooltip: "Reply to this message"

2. Click behavior

   • Focus the composer input
   • Insert `` directive at cursor start
   • Optionally show a preview pill above composer: "Replying to: [message preview]"

3. Visual feedback

   • Highlight the quoted message temporarily
   • Show quote preview in composer area (like Telegram/WhatsApp)
   • Clear quote on send or cancel (X button)

Technical Implementation

Files to modify:

• dist/control-ui/assets/index-B5x_BDbc.js — Add button rendering + click handler
• dist/control-ui/assets/index-Da9vddnh.css — Button styles
• Optionally: src/ source files if rebuilding from source

Key integration points:

• Message ID: Extract from chat.history message objects (field: id)
• Directive insertion: Prepend `` to composer value
• Preview: Parse message content for preview text (strip markdown, limit length)

---

Relation to Existing Issues

This is a specific subset of the broader inline button request:

• Related: #46656 — Webchat inline button support (buttons parameter, callback RPC)
• Related: #88032 — Telegram quote/reply context as first-class contract

This request is simpler than #46656 because:

• No new gateway protocol needed (backend already supports reply_to directives)
• No callback RPC needed (reply is handled via normal message flow)
• UI-only change: add button → insert existing directive

---

Use Cases

1. Threaded discussions — Reply to a specific point in a long conversation
2. Clarification — "What did you mean by [quoted message]?"
3. Multi-topic chats — Keep parallel conversations organized
4. Reference context — Quote earlier messages when asking follow-up questions

---

Mockup (ASCII)

Problem to solve

Users cannot easily reply to specific messages in Webchat Control UI.

The backend already supports reply-to-message via and directives, but there is no UI button to trigger this. Users must manually type the directive, which is not discoverable and hurts usability.

This is a basic chat feature available in Telegram, WhatsApp, Slack, Discord, and Feishu — all of which have a quote/reply button on message bubbles.

Proposed solution

Add a "Quote/Reply" button (↩️) to each message bubble in Control UI webchat:

1. Click button → composer focuses and inserts `` directive
2. Show preview pill above composer: "Replying to: [message preview]"
3. Send normally — backend already processes the reply_to directive

Files to modify:

• dist/control-ui/assets/index-B5x_BDbc.js (button rendering + click handler)
• dist/control-ui/assets/index-Da9vddnh.css (styles)

No gateway protocol change needed — backend already supports this.

Alternatives considered

No response

Impact

User-facing quality-of-life improvement for Webchat Control UI users.

• Affects: All Webchat/Control UI users (direct message interface)
• Severity: Low — current workaround exists (manual directive typing)
• Frequency: High — reply/threading is a common chat pattern
• Risk: Low — uses existing backend protocol, no new data exposure

Without this: Users can still reply, but the flow is non-discoverable and clunky. With this: Parity with Telegram/WhatsApp/Slack basic chat UX.

Evidence/examples

No response

Additional information

No response