Bug: Double clicking file in parent column causes file area to scroll (Columns View)

[zbt00123]

Description

Double‑click behavior inconsistency in Columns view

Folder structure:
Desktop
└─ Test_A
├─ Layer_1
│ ├─ 2D
│ ├─ 3D
│ ├─ Comp
│ │ ├─ (Footage)
│ │ └─ Word_A.txt
│ └─ Refs
└─ Word_B.txt

Observation (Columns view enabled):

Mac_1.mp4

-------- macOS --------

Files_1.mp4

-------- Files --------

• In macOS Finder, as shown in the attached video, after double‑clicking Word_A.txt to open it, I can immediately double‑click Word_B.txt without any unexpected window jumps. The navigation remains smooth and predictable.

• In Files, however, due to the current window‑handling logic, double‑clicking Word_B.txt results in the following misbehavior:

  1. The first click of the double‑click selects Word_B.txt, which triggers a window navigation (folder content jumps).
  2. Because the window jumps during that first click, the second click of the double‑click is no longer registered on Word_B.txt – instead, it lands on the empty background area of the desktop (or an unintended region).

Impact:
This breaks the intuitive double‑click workflow, especially when users need to quickly open multiple files in succession. The erratic navigation forces users to re‑acquire the target file, reducing efficiency and causing confusion.

Suggested alignment:
Adopt the robust focus and navigation behavior seen in macOS Finder, where double‑click actions are reliably processed without intermediate window jumps, ensuring that both clicks of the double‑click are consistently applied to the intended file.

Steps To Reproduce

As mentioned above.

Files Version

4.2.0.0

Windows Version

10.0.26200.8737

User ID

5be1ab97-a6f8-4ceb-8e51-64d2d86df27a

Log File

debug.log

[yair100]

@zbt00123 first of all, thank you for sharing your feedback. It's a bit hard to follow this issue, can you please fill out the issue template as well as basic steps to reproduce the issue (the screen recordings are helpful, but we like to have the steps written out as well)? This makes it easier for us to understand the issue and hopefully solve it quicker.

[zbt00123]

@zbt00123 first of all, thank you for sharing your feedback. It's a bit hard to follow this issue, can you please fill out the issue template as well as basic steps to reproduce the issue (the screen recordings are helpful, but we like to have the steps written out as well)? This makes it easier for us to understand the issue and hopefully solve it quicker. This makes it easier for us to understand the issue and hopefully solve it quicker.

Expected behavior

1. Keep the target stable during a double-click

When a user double-clicks a file in Columns view, the file and the view should remain stable between the first and second click.

The first click should not trigger a Columns view shift or repositioning that moves the file away from the mouse pointer before the second click is received.

The expected operation is:

Point to file A → double-click file A → file A opens

In short:

The original click target should remain stable until the double-click operation is completed.

---

2. Treat the selected folder as the current operation target

When a folder is visibly selected/highlighted, that folder should automatically become the target for relevant file operations.

For example:

Select folder BBB → Ctrl+V → paste the copied item into BBB

Select folder BBB → Create New Folder → create the new folder inside BBB

The user should not need to open the selected folder or click inside its content area first.

In short:

Selected folder = current operation target.

[yair100]

Thank you, this is definitely not the desired behavior.

[zbt00123]

Thank you, this is definitely not the desired behavior.

Thank you very much for your recognition. In my view, macOS Finder has many commendable aspects in file operations. Although it is not as feature-rich as Files in terms of functionality, it aligns with user intuition in basic operations. Apple has consistently adhered to intuitive interaction paradigms in its software design, and there are virtually no unexpected responses that violate user expectations.

This is also why I remain committed to Files. In my opinion, Files is fully capable of integrating the strengths of Finder and can functionally outperform any existing file manager. The potential of Files is boundless, and I would like to take this opportunity to thank all the developers for their efforts. I will continue to use Files.