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

[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.

[juliusmarminge]

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.