Closes #1710

Summary

The workspace file-tree row tooltip says "Double-click to rename" on every entry — including folders. But double-clicking a folder navigates into it (loadDir()); rename for folders lives only in the right-click context menu. The tooltip is therefore misleading on directory rows.

Reported by @Deor in the WebUI Discord testers thread (May 5 2026), responding to the #1698 fix:

Ah that works yeah. May want to change the popup text as it also says double click at the moment.

Fix

static/ui.js _renderTreeItems — gate the nameEl.title assignment on item.type !== 'dir'. Files keep the existing hint that matches their dblclick behaviour. Folders get no tooltip (rename still reachable via the right-click → Rename context menu, which is unchanged). 4 lines of code change.

-    nameEl.className='file-name';nameEl.textContent=item.name;nameEl.title=t('double_click_rename');
+    nameEl.className='file-name';nameEl.textContent=item.name;
+    // Tooltip only on FILES — dblclick renames them. On directories, dblclick
+    // navigates into the folder; rename lives in the right-click context menu
+    // (the "Double-click to rename" hint here would be misleading). #1710.
+    if(item.type!=='dir')nameEl.title=t('double_click_rename');

Why not remove the tooltip entirely

@AvidFuturist asked whether to drop it on files too. Keeping it on files is reasonable — dblclick-to-rename is non-obvious on a chat app's workspace pane (vs. a native file manager), and the tooltip is the primary discoverability path. Removing it on folders alone fixes the misleading affordance without losing useful discoverability for files.

Companion to the rename-affordance triage

• bug(workspace): can't rename files from tree — first click of dblclick opens preview, dblclick handler unreachable #1698 fixed: dblclick rename was unreachable on files (preview hijacked the first click)
• v0.51.4 — 10-PR full-sweep batch #1707 fixed: single-click on filename did nothing (the bug(workspace): can't rename files from tree — first click of dblclick opens preview, dblclick handler unreachable #1698 fix was over-aggressive)
• bug(workspace): 'Double-click to rename' tooltip shows on folders too — but dblclick on a folder navigates, doesn't rename #1710 (this PR): tooltip claimed dblclick-rename on folders too

After this lands, the file-tree click affordances are consistent with what each click actually does.

Tests

4 new source-level regression tests in tests/test_1710_folder_tooltip.py:

• test_tooltip_assignment_is_guarded_by_item_type — locks the if(item.type!=='dir') guard around the nameEl.title assignment so a future refactor can't reintroduce the unconditional tooltip.
• test_dir_dblclick_still_navigates_not_renames — sanity: directory dblclick still calls loadDir(item.path), the navigate-not-rename contract this PR depends on.
• test_files_still_get_tooltip — locks that files retain the i18n-keyed tooltip.
• test_i18n_key_still_defined_in_all_locales — the double_click_rename key must remain defined in ≥5 locale blocks of static/i18n.js.

Result: 4 new + 9 existing #1707 tests = 13 passing for the file-tree handler block. Targeted suite (tests/test_1710*.py tests/test_1707*.py) passes locally; broader workspace/rename pattern (264 tests) also passes.

Reporter

@Deor via WebUI Discord testers thread (May 5 2026 09:34 UTC).