Skip to content

[Bug]: Mobile queued-message Remove action cannot be tapped #15414

Description

@PixPMusic

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

  1. Have a queued message in a thread in the native mobile app.
  2. Open the Queued sheet.
  3. Swipe the message left to expose the red Remove action.
  4. Tap Remove.

Expected behavior

The selected message is removed from the queue. Other queued messages remain.

Actual behavior

The red Remove action does not respond to taps. Its implementation renders a noninteractive View containing the trash icon and label, without a press handler. The long-press menu has a separate working removal command.

Source: QueueRowSwipeable on main at 88744f3d.

Impact

Minor bug or occasional failure: the visible removal action cannot be used; removal is available through the row's long-press menu.

Version or commit

Source confirmed on main @ 88744f3. The installed version in the original report is unknown.

Environment

Reported on Android. The queue row implementation is shared by Android and iOS.

Workaround

Long-press the queued message and choose Remove from the menu.

Activity

  1. juliusmarminge commented on Oct 4, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks for the clear report and the source link, @PixPMusic. I could confirm this on main at 88744f3. If you swipe a queued message left and tap the red Remove control, nothing happens. Long-press, then Remove, still works.

    What's happening

    In QueueRowSwipeable (apps/mobile/src/features/threads/ThreadQueueControl.tsx), renderRightActions draws the Remove control as a plain View with the trash icon and label. It has no press handler, so a tap does nothing.

    The component only calls onRemove from onSwipeableOpen when direction === "right". With react-native-gesture-handler 3.2.1, that argument is the direction of the swipe, not which side's actions opened. Swiping left to open the right-hand actions reports "left", so the handler returns early. The row then stays open on a label you can't tap. The row has no left actions, so the "right" branch never runs.

    The removal logic is fine. The long-press Remove item calls act(run.id, "remove"), which cancels just that queued run and leaves the others alone. For comparison, thread rows in apps/mobile/src/features/home/thread-swipe-actions.tsx wrap their revealed action in a Pressable, but this sheet doesn't. Android and iOS share this component, so both should be affected.

    I didn't find a duplicate. Until there's a fix, long-pressing the row and choosing Remove is the right workaround.

    Likely fix area

    One option is to make the visible Remove control call the existing onRemove callback, for example by wrapping it in a Pressable like the thread rows. If a full swipe should also remove the message, onSwipeableOpen could treat "left" as the commit direction.

    A maintainer will decide on the fix direction.

  2. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions