[Due for payment 2026-03-11] Distance - Waypoint cannot be dragged after rearranging via keyboard

[mitarachim]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.6-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #79793
Email or phone of affected tester (no customers): jnoijnojiojiojnioni@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Click + > Track distance > Map.
3. Enter Start and Stop waypoint.
4. Press Tab until it reaches Start waypoint.
5. Press keyboard space, down arrow, and Enter.
6. Press Enter again.
7. Long click on Start or Stop point and try to drag it.

Expected Result:

The waypoint can be dragged.

Actual Result:

The waypoint cannot be dragged after rearranging via keyboard.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7055110_1769038447778.1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #79793

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #79793 - "feat: implement keyboard reordering for DraggableList" by @MobileMage (High confidence)
Related Issues: None

Recommendation: REVERT

This PR introduced keyboard reordering functionality to DraggableList, but it causes pointer-based dragging to fail after keyboard navigation is used. The bug is reproducible only in staging (where PR #79793 exists) and affects the core drag-and-drop functionality for waypoints. Since this breaks existing drag functionality after using the new keyboard feature, the safest approach is to revert and fix the interaction between KeyboardSensor and PointerSensor before re-landing.

Labels: Keeping DeployBlockerCash (App deploy blocker). Removing DeployBlocker as this is a frontend bug requiring changes in the App repository only.

📋 Detailed Analysis

Evidence

• The issue specifically mentions that drag functionality breaks after using keyboard navigation (steps 4-6 in repro)
• PR feat: implement keyboard reordering for DraggableList #79793 is the only PR in the v9.3.6-0 deploy that touches DraggableList
• The PR added KeyboardSensor to enable keyboard-based reordering of waypoints
• The bug was caught during regression testing and is confirmed to reproduce on staging
• The issue author explicitly linked PR feat: implement keyboard reordering for DraggableList #79793 in the bug report

Verification

• File affected: src/components/DraggableList/index.tsx (keyboard navigation for waypoints)
• Confirmed PR modifies this file: Yes - PR feat: implement keyboard reordering for DraggableList #79793 modified src/components/DraggableList/index.tsx
• Changes made in PR:
  • Added KeyboardSensor alongside existing PointerSensor
  • Configured sensors using useSensors() hook
  • Added sortableKeyboardCoordinates for keyboard navigation

Root Cause

The PR introduced both KeyboardSensor and PointerSensor to the DndContext using the useSensors hook. However, there appears to be a state management issue where after keyboard-initiated drag operations complete, the pointer-based dragging becomes non-functional.

Possible technical reasons:

1. Sensor state conflict: After keyboard drag completes, internal dnd-kit state may not properly reset, leaving the PointerSensor in a disabled or confused state
2. Focus management: The tabIndex={-1} in SortableItem (added to prevent double focus) combined with keyboard interaction may be preventing proper re-focusing needed for subsequent pointer events
3. Event listener registration: The listeners object from useSortable may not be properly re-registering pointer events after keyboard sensor activates

The code change appears correct in isolation, but the interaction between the two sensors requires additional handling to ensure they don't interfere with each other.