fix: tab-menu-dropdown not opening on non-active tabs

[Copilot]

Clicking the ⋯ menu on a non-active tab triggered switchTab() alongside the menu handler — even with e.stopPropagation() in place — causing renderTabBar() to immediately rebuild the DOM and destroy the freshly-opened dropdown. The active tab was unaffected because switchTab returns early when the tab is already active.

Changes

• script.js / desktop-app/resources/js/script.js: Added a guard in both the desktop and mobile tab-item click handlers to bail out early when the click originates from within .tab-menu-btn:

item.addEventListener('click', function(e) {
  if (e.target.closest('.tab-menu-btn')) return;
  switchTab(tab.id);
});

This prevents the tab-switch + DOM rebuild race regardless of whether stopPropagation succeeds, keeping the dropdown alive for any tab.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
markdown-viwer	Ready	Preview, Comment	May 5, 2026 9:26am

[Copilot]

Pull request overview

This PR fixes a tab-bar interaction bug where clicking the three-dot menu on an inactive tab could also trigger switchTab(), causing the tab bar to re-render and immediately remove the opened dropdown. It applies the fix to both the main web script and the mirrored desktop app resource so behavior stays consistent across builds.

Changes:

• Added a guard in the desktop tab click handler to ignore clicks originating inside .tab-menu-btn.
• Added the same guard in the mobile tab-list click handler to prevent tab switching when opening the menu.
• Kept the duplicated desktop app script in sync with the root web script.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
script.js	Adds the menu-origin click guard in the main web tab bar and mobile tab list handlers.
desktop-app/resources/js/script.js	Mirrors the same click-guard fix for the desktop-packaged web assets.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ThisIs-Developer]

Currently, file-specific actions (rename, duplicate, delete) are only accessible for the active/open file. This creates unnecessary friction when managing multiple files.
Observed Behavior:
When working in Untitled 3, attempting to access the three-dot menu for Untitled 1 does not open its action dropdown.
The dropdown becomes available only after switching focus to Untitled 1.
Expected Behavior:
Users should be able to access the action menu (three-dot button) for any file in the file list, regardless of which file is currently open.

[Copilot]

Currently, file-specific actions (rename, duplicate, delete) are only accessible for the active/open file. This creates unnecessary friction when managing multiple files.
Observed Behavior:
When worki...

This is exactly what commit ec14dba fixes. The root cause was that clicking the ⋯ button on a non-active tab also triggered the parent tab-item click handler, which called switchTab() → renderTabBar() and tore down the freshly-opened dropdown before it could be seen. For the active tab, switchTab returns early so the re-render never happened, making it look like the menu only worked there.

The fix adds a guard to both the desktop and mobile tab-item click handlers:

item.addEventListener('click', function(e) {
  if (e.target.closest('.tab-menu-btn')) return;
  switchTab(tab.id);
});

Now the ⋯ dropdown opens on any tab in the list — Untitled 1, Untitled 2, Untitled 3, etc. — without needing to switch to that tab first.