[Feature][Mobile] Add a Web search action when selecting text in chat messages

[bribeck]

Description

When selecting text in a chat message in the T3 Code mobile app (Android, Play Store 1.1.0), the selection menu has no way to search the selected text on the web. Other apps (e.g. Chrome, most messaging apps) offer a "Web search" / "Search" action in the text selection toolbar, which makes it quick to look up product names, terms, or errors mentioned in an assistant response.

Android chat markdown uses a custom selectable renderer (#8779, SelectableMarkdownText.android.tsx / @t3tools/mobile-markdown-text), which may be why the system "Web search" action isn't shown.

Expected behavior

• Selecting text in a chat message shows a Web search (or Search) action alongside Copy / Select all.
• Tapping it opens the user's default browser/search app with the selected text as the query (e.g. Android Intent.ACTION_WEB_SEARCH, or a search URL fallback).
• Ideally the same on iOS (the system "Search Web" / "Look Up" items).

Related

• [Feature]: Allow native text selection within assistant responses #5342 — native text selection within assistant responses (closed)
• Feature: reply to selected assistant response text #6456 — reply to selected assistant response text (closed)
• feat(mobile): make chat text selectable on Android #8779 — Android selectable markdown

[juliusmarminge]

Triage

Valid enhancement. Confirmed on current main (f17165a76). Selecting chat markdown on Android still has no Web search action. The menu is Copy / Share / Select all. Not already fixed. Not a duplicate of #5342 or #8779.

What you reported. On Android (Play Store 1.1.0), selecting text in a chat message shows no Web search / Search action. Other apps put that in the selection toolbar so you can look up a product name, term, or error from an assistant reply. You pointed at the custom selectable renderer (SelectableMarkdownText.android.tsx / @t3tools/mobile-markdown-text, #8779) as the reason the system action is missing. You want Intent.ACTION_WEB_SEARCH (or a search-URL fallback), and the same on iOS if system Search Web / Look Up are missing.

That matches the code.

What the code does

1. Android chat text is selectable RN Text, not a custom toolbar.

hasNativeSelectableMarkdownText() is true on Android (apps/mobile/src/native/SelectableMarkdownText.android.tsx). User and assistant bodies in ThreadFeed.tsx go through SelectableMarkdownText. The module comment is accurate: outside iOS the renderer falls back to React Native Text (MarkdownTextPrimitive.tsx:166-171). #8779’s own write-up of that menu is Copy / Share / Select all. It never added Web search, and nothing later did (git log on the Android markdown module has no ACTION_WEB_SEARCH / Web search commit).

2. The only custom ActionMode is a Copy sanitizer, and it is not always installed.

SanitizingSelectionActionModeCallback (T3MarkdownTextSelectionModule.kt:122-166) wraps customSelectionActionModeCallback and intercepts only android.R.id.copy, so image spacers / context chips copy as plain (or context) text. onCreateActionMode / onPrepareActionMode only delegate. They never insert a menu item.

installCopySanitizer is called only when the chunk has an inline icon (NativeMarkdownSelectableText.tsx:299-306: Platform.OS !== "android" || !containsInlineIcon returns). Plain assistant prose — the usual “search this error” case — never gets a custom callback. AOSP TextView/Editor on current APIs populate Copy / Select all / Share and PROCESS_TEXT activities. They do not add Intent.ACTION_WEB_SEARCH. Chrome/Messages add that themselves. T3 does not.

3. Code blocks are the same RN selection path.

HighlightedCodeText (NativeMarkdownBlock.tsx:136-145) is also selectable MarkdownTextPrimitive with no sanitizer and no extra actions. Whole-block copy is the header CopyTextButton. Out of scope unless the ActionMode is installed at the Android Text root.

4. iOS already defers to the system edit menu.

iOS uses a real UITextView (T3ContextCopyTextView). canPerformAction:withSender: only special-cases selectAll: and then calls super (T3MarkdownText.mm:37-43). The outside-tap clear even names Copy / Define / Look Up as in-flight actions (T3MarkdownText.mm:687-688). System Search Web / Look Up should already appear. Do not add a custom iOS item unless a device check shows they are gone.

5. No later commit or open PR implements this.

HEAD f17165a76 (fix(web): preserve thread reading positions). No open PR references #12196. #11841 only retinted Android selection handles.

Not a duplicate

Work	Why this is still open
#5342 (closed)	Native range selection in assistant replies. Shipped; this is the next action on that menu.
#8779 (merged)	Android selectable markdown. Documented menu is Copy / Share / Select all.
#6456 (closed)	Reply with a quoted selection on web/desktop. Different action; mobile was explicitly out of that first pass.
#11297 (open)	SwiftUI: select across blocks and copy Markdown. Different client and job.
#11128 (merged)	Rename shared renderer; no menu actions.

Suggested smallest scope

Stay on the Android selection ActionMode for chat markdown. Do not add a JS action sheet. Do not change web/desktop (the browser already searches a selection). Do not implement Reply (#6456) or SwiftUI cross-block copy (#11297) here.

• Add a Web search item on SanitizingSelectionActionModeCallback (or a renamed callback that still sanitizes Copy).
• Install that callback on every Android selectable markdown root, not only containsInlineIcon.
• On tap: sanitized selected text (same as Copy: strip \uFFFC / NBSP spacers, use canonical context labels). Then Intent.ACTION_WEB_SEARCH + SearchManager.QUERY. If nothing resolves it, ACTION_VIEW a search URL.
• onPrepareActionMode must not return false after adding the item (today’s delegate ?: false can skip a menu refresh).
• iOS: confirm system Search Web / Look Up; no custom item unless they are missing.
• Leave Copy / Share / Select all and the copy sanitizer alone.

Next step

Accepted. Small, localized Android ActionMode change in @t3tools/mobile-markdown-text. Keep this issue open until a mobile-only PR lands. Treat iOS as verify-only unless a device shows the system items are gone.