ADFA-4320 Paper cut: Fix for swiping bottom sheet tabs incorrectly opening file menu

[hal-eisen-adfa]

Problem

Fling-strength swipes between bottom-pane tabs (Build Output / IDE Logs / Diagnostics / Git etc.) were triggering BaseEditorActivity's drawer-open gesture detector and popping the file tree open mid-swipe. No edge proximity required — pure horizontal velocity on the tab strip.

Change

In BaseEditorActivity.onFling, the existing isDrawerOpenFling branch now also checks !isTouchOnBottomSheetTabs(e1) before calling openDrawer. The hit-test reads contentOrNull?.bottomSheet?.binding?.tabs (safe during teardown), grabs the TabLayout's getGlobalVisibleRect, and tests (e1.rawX, e1.rawY) against it.

The check lives alongside the other fling filters (startedNearTopEdge, noFilesOpen, …) so the suppression rule is visible to anyone editing setupGestureDetector.

Scope

• Hamburger menu unaffected (works in every bottom-pane state).
• DrawerLayout's left-edge swipe unaffected.
• Fullscreen exit-edge flings unaffected.
• The no-files horizontal-fling drawer shortcut still fires for flings outside the tab strip.

Test plan

• Open a project with at least one file. Expand the bottom pane.
• Fling the tab strip left and right with momentum — drawer must not appear.
• Tap the hamburger from collapsed / half-expanded / fully expanded states — drawer opens every time.
• Swipe from the screen's left edge over the editor area — drawer still opens.
• In the empty no-files state, do a strong rightward fling on the editor area (outside the tab strip) — drawer still opens.
• Background → foreground → swipe tabs — no crash.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7daa95b3-27e9-46cc-ab23-303e7805dc07

📥 Commits

Reviewing files that changed from the base of the PR and between 53f843f and f8b49bd.

📒 Files selected for processing (1)

• app/src/main/java/com/itsaky/androidide/activities/editor/BaseEditorActivity.kt

🚧 Files skipped from review as they are similar to previous changes (1)

• app/src/main/java/com/itsaky/androidide/activities/editor/BaseEditorActivity.kt

---

📝 Walkthrough

• Fixed an issue where strong horizontal swipes on bottom-sheet tabs could incorrectly trigger the drawer-open fling gesture and open the file tree.
• Updated BaseEditorActivity.onFling to ignore drawer-open flings that start within the bottom-sheet tab strip by hit-testing the tabs’ global visible bounds against the fling’s initial touch point.
• Preserved existing drawer behavior for the hamburger menu, left-edge drawer swipes, fullscreen exit-edge flings, and the no-files horizontal-fling shortcut when swipes begin outside the tabs.
• Risk: the new guard depends on the tab layout’s global visible rectangle and raw touch coordinates, so layout/inset changes could affect hit-testing if the tab strip position or visibility behavior changes.

Walkthrough

BaseEditorActivity's drawer-open swipe handling now checks whether a right-swipe fling originates on the bottom-sheet tab strip and suppresses the drawer-open action if it does. The change adds an android.graphics.Rect import, a new isTouchOnBottomSheetTabs(MotionEvent) helper, and updates the GestureDetector onFling condition.

Changes

Drawer Gesture Suppression for Bottom-Sheet Tabs

Layer / File(s)	Summary
Bottom-sheet tab hit-test and onFling condition app/src/main/java/com/itsaky/androidide/activities/editor/BaseEditorActivity.kt	Adds Rect import, introduces isTouchOnBottomSheetTabs to check whether a touch's raw coordinates fall within the bottom-sheet TabLayout's global visible rectangle, and updates the onFling condition to open the drawer only when isDrawerOpenFling is true and the fling start is not on the tab strip.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• dara-abijo-adfa

Poem

🐇 A swipe on the tabs? The drawer stays tight,
No gesture shall snatch what the coder writes.
The Rect marks the bounds, the fling checks the gate,
Right-swipes on tabs simply have to wait!
Hop hop, little fix — you've earned your delight! 🎉

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: preventing bottom sheet tab swipes from opening the file menu.
Description check	✅ Passed	The description matches the changeset and accurately explains the problem, fix, and unaffected behavior.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ADFA-4320-paper-cut-flinging-the-tabs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@app/src/main/java/com/itsaky/androidide/ui/EditorBottomSheet.kt`:
- Around line 271-285: The drawerLockCallback object only updates the drawer
lock mode when onStateChanged is invoked, which means if the bottom sheet is
already in an expanded or half-expanded state when the callback is registered,
the drawer will remain unlocked until the next state transition occurs. After
the callback registration at the .also block where
behavior.addBottomSheetCallback is called, immediately apply the drawer lock
mode based on the bottom sheet behavior's current state using the same lock
logic (checking if the current state is STATE_COLLAPSED or STATE_HIDDEN to
unlock, otherwise lock). This ensures the drawer lock state is correct
regardless of whether the sheet is already expanded when the callback is
attached.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ccadc028-3ecf-4f41-a82a-dfc0dd0b2135

📥 Commits

Reviewing files that changed from the base of the PR and between 4d9b100 and da1e435.

📒 Files selected for processing (1)

• app/src/main/java/com/itsaky/androidide/ui/EditorBottomSheet.kt