Clicking a filename and getting only its folder adds another search. Opening a document app when the person wanted its location is just as unhelpful. I gave the filename and adjacent folder control different purposes, with different evidence for whether the requested action was dispatched.
Three different intentions hide inside the word open
Opening the overall downloads directory, revealing one saved file in the file manager, and opening that file through its default application are different intentions. The directory locates storage, the per-file folder control points to the saved item, and the filename continues work in an associated app.
In the source, openDownload actually calls shell.showItemInFolder. The open branch of downloadAction calls shell.openPath. Explaining behavior from an internal function name alone could reverse the two meanings. I followed the final shell calls as well as the documentation and interface labels so the account reflects what each action actually dispatches.
Target a completed file owned by the current profile
Both per-file operations go through completedDownload. It requires a completed record for the current profile and uses lstat to check that its recorded path still refers to a file. If the item was moved or deleted, it reports the problem rather than searching for another same-named file. A profile change during the await is checked as well.
This is not a content-safety scan or a lock held over the filesystem. It checks the current target of the history ID. A name appearing while transfer is still running does not make the file eligible for the default app. Interface capability and host validation work together to avoid treating a partial result as ready to open.
A small popup request still crosses a trust boundary
The popup schema distinguishes open, reveal and folder. Its IPC handler checks the sender window and main frame against the actual downloads surface, validates action shape and requires a per-file ID to exist in current state. A filename supplied by a webpage does not become an operating-system path directly.
Reveal is routed to location display, while open goes through file control; after opening, the transient window is closed if still alive. New windows and navigation of the popup itself are blocked. This account does not certify every security property of that surface. It traces the concrete checks and dispatch behind a click so those smaller claims remain reviewable.
Handing a file to the default app is not reading its contents
A nonempty shell.openPath error produces a message about the associated application. An empty return reports the operating-system open request, not complete rendering of a document or proof that the person read it. Text, video and PDF may each need different follow-up display checks.
The existing native test wraps shell.openPath while still calling the original function, recording the actual target and returned error. It then compares that target and saved contents. Another UI test uses dispatch-recording substitutes to check exact routing. Those two kinds of evidence should not both be described as full rendered-document verification; each answers its own narrower question.
Retain the destination alongside the button description
The native folder test checks the configured downloads directory, returned error and actual directory existence after the shell request. The filename test uses the exact path of a downloaded item. Saying open succeeded without identifying its destination would leave the person's original intention unverified.
I read those selected source and test ranges without opening a real user's files or default applications. The shared file-receipt module also implements no operating-system open operation. An administrator interface can reuse the design distinction between overall storage, an item's location and the item itself, with wording and dispatch evidence that let the user predict which action each control performs.