macOS desktop: PDF download-menu selections are dismissed by PDF pointerdown focus capture
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, react
Research direction
The report identifies the PDF wrapper’s onPointerDownCapture handler in webview/assets/pdf-preview-panel-d785032c3306.js and describes a reproduction using React 19.2.7 and the dropdown components. Read the handler and check whether its target is inside the wrapper before it focuses the section, while preserving the interactive-element exclusions. Reproduce mouse selection and PDF canvas focus; done means the menu action runs and canvas clicks still focus the PDF.
Written by the indexing model from the issue text.
Description
App: 26.1013.40934 (20770), production macOS arm64; bundle id com.openai.codex.
Problem
In a local PDF preview, opening the top-right download menu and clicking Show in Finder closes the menu without revealing the file. Selecting another native application from the same menu also has no effect. The same file can be revealed through the chat-body file-link context menu and with the native open -R command. A fresh preview, a new window, and closing the original window do not resolve it.
Confirmed mechanism
The PDF Pn wrapper in webview/assets/pdf-preview-panel-d785032c3306.js attaches an onPointerDownCapture handler that focuses its section whenever the pointer target is not inside input, textarea, button, a, or contenteditable=true. It does not check whether the event target is actually inside that section in the DOM.
The dropdown menu items render as div elements, commonly with span text children, and the dropdown content is portaled outside the PDF section. React still propagates those events through the parent component tree. Consequently, pressing a menu item causes the PDF wrapper to focus itself. The dropdown receives focusOutside and unmounts before the browser dispatches the item's click. Its onSelect handler never runs.
Observed local performance trace
The failing pointerdown has CPU samples showing the PDF y handler calling HTMLElement.focus. The same event contains blur/focusout, focus/focusin, dismissableLayer.focusOutside, and dropdown cleanup. The later pointerup/mouseup occur after removal, with no menu-item click dispatched. This happens before the optional file-watch preparation hook and before the external-open RPC.
Independent reproduction and validation
A localhost reproduction uses the exact installed React 19.2.7 and dropdown components together with the exact PDF focus callback:
- Original handler, mouse selection: menu closes, action callback count stays 0.
- Corrected handler, mouse selection: action callback runs once.
- Original handler, keyboard selection: action callback runs once in the reproduction.
- Corrected handler, pointer on the PDF canvas: the PDF section still receives focus.
The affected user also confirmed that selecting Show in Finder with the arrow keys and Enter in the actual installed PDF preview successfully reveals the file. The standalone reproduction uses an action counter; no locally patched application is being presented as installed.
Suggested minimal fix
Before focusing the PDF section, require event.currentTarget.contains(event.target). Preserve the existing interactive-element exclusions. This excludes pointer events from descendant React portals that are outside the section's actual DOM subtree.
Privacy and installation status
The report contains no personal paths, PDF content, account or conversation identifiers. Raw performance traces and logs remain local. The signed, integrity-checked installed application has not been modified. This report establishes a code defect and a verified source-level repair, not an installed-app fix.
- Dominant language
- Rust
- Stars
- 130k
- Forks
- 20.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 997
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
bug CLI config mcp
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
app bug context windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
CLI config enhancement mcp
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
openai/codex#55786 · 1 reaction ·
Maintainers usually reply within 1 day
-
bug CLI TUI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
Similar issues
-
documentation priority:p2 type:chore
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
dispatch:sol-high documentation
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
carrick-sh/carrick#768 · 1 comment ·
Maintainers usually reply within 1 day
-
correctness postgres tursopg
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
tursodatabase/turso#10442 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
ankitects/anki#5864 · 1 reaction ·
Maintainers usually reply within 2 days
-
area: config effort: S good first issue P3 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ferenyl/azuredevopstui#63 ·