[bug][alpha] FileExplorer: sort-menu state and outside-click handler are dead code (`showSortMenu` never opens; `sortMenuRef` never attached)

[BugH-00]

Project

ide

Description

FileExplorer (src/components/FileExplorer.tsx) declares showSortMenu, setShowSortMenu, sortMenuRef, and a createEffect that registers document mousedown to close the menu when clicking outside.

Nothing in the component ever calls setShowSortMenu(true), and sortMenuRef is never bound to a DOM node (ref={sortMenuRef} does not exist). The outside-click branch therefore never runs meaningfully (sortMenuRef stays undefined), and no sort dropdown is rendered.

Explorer sort order remains the real explorer.sortOrder setting (Settings UI / SettingsContext) — this block is orphaned scaffolding, not the live sort path.

Single root cause: unfinished or abandoned quick-sort UI left in the tree without a trigger or menu markup.

Error Message

Debug Logs

System Information

Cortex IDE alpha
File: src/components/FileExplorer.tsx

Screenshots

Steps to Reproduce

1. Open Files sidebar with a folder loaded.
2. Search the component (or UI) for any control that sets showSortMenu to true — none exists.
3. Confirm no element assigns sortMenuRef.

Expected Behavior

Either remove the unused signals/effect or implement a visible sort control wired to the same model as Settings (explorer.sortOrder), with sortMenuRef on the menu root.

Actual Behavior

Dead code path; no user-facing sort menu from this state.

Additional Context

No response

[echobt]

❌ Invalid

INVALID: Dead code analysis is not a valid UI bug report.

This issue reports 'dead code' in FileExplorer.tsx - specifically that showSortMenu state and sortMenuRef exist but are never triggered or bound to DOM elements. While the code analysis is technically accurate (verified in src/components/FileExplorer.tsx lines 186-200), this is NOT a user-facing UI bug.

Key findings:

1. The FileExplorer component IS accessible via ActivityBar → Files sidebar (confirmed in CortexSidebarContainer.tsx)
2. The sort menu code exists but is never rendered to users - there is no trigger button or UI element
3. Users control sort order through Settings (SettingsContext) instead, which works correctly
4. From a user perspective, there is NO broken or malfunctioning UI - they simply use the Settings path for sort order

Why this is invalid:

• This is incomplete/abandoned scaffolding code, not a visible bug
• No user is blocked or frustrated - the feature works via Settings
• This is essentially a code cleanup request, not a bug report
• The screenshot URL returned 404 (no visual proof of any bug)

Comparison to similar issues:

• Issue [BUG] [v1.0.0] Sort menu has no outside-click close behavior and can remain stuck open #24096 (PromptStore sort menu) was VALID because the menu DID open but lacked outside-click handler - users experienced a stuck dropdown
• This issue describes code that NEVER manifests in the UI - users never see any broken sort menu in FileExplorer

The proper resolution is to remove the dead code or implement the feature, but this is not a bounty-eligible UI bug.

[willkhinz]

I've got a surgical fix for this. Just running some quick local tests and will post the PR soon.

[willkhinz]

I have opened a Pull Request with the fix here: #38249

Thanks!