Copy and paste doesn't work in Finder dialogs
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox152 | --- | fixed |
People
(Reporter: flod, Assigned: spohl)
References
Details
Attachments
(1 file)
Try to save a file, and to paste a name in the file name field. For some reason, this doesn't work in Firefox, but works fine in Chrome, although the two dialogs look the same (the only difference, Firefox displays the file extension). Right-click and Paste works.
This is happening with Nightly on macOS Tahoe 26.3.1 (a) (25D771280a)
| Assignee | ||
Comment 2•1 month ago
|
||
Looking into it. Possibly a regression from bug 2035989.
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Comment 3•1 month ago
|
||
After bug 1909546 the macOS file picker is presented as an
NSSavePanel/NSOpenPanel sheet attached to a parent window via
beginSheetModalForWindow:. The sheet's filename field is the key
window's first responder and natively implements paste:, cut:, undo:
etc., but Cmd+V and friends don't reach it. Bug 2035989 made File >
Open File... usable from non-browser chrome windows, which exposed
this pre-existing wiring problem -- the file picker now appears in a
usable position so users actually try to paste into it.
Bug 2035195, currently in review, migrates the system print dialog
off [NSPrintPanel runModal] to a window-modal sheet via
beginSheetWithPrintInfo:modalForWindow:. That removes
nsCocoaUtils::PrepareForNativeAppModalDialog -- whose menu-bar swap
to nsMenuUtilsX::GetStandardEditMenuItem was today's only reason
Cmd+C/V/X/Z/A worked inside any sheet-modal native dialog -- so the
print dialog inherits the same bug as soon as 2035195 lands. This
patch fixes both call sites with one change, and lets bug 2035195's
removal of the menu-bar swap keep its claim that the parent window's
edit menu preserves keyboard shortcuts inside the dialog.
Why the keystroke never reaches the sheet: the Edit menu items were
all wired to action=menuItemHit: with target=sNativeEventTarget (a
fixed object). With a fixed target, [NSApplication sendEvent:] asks
the menu bar via performKeyEquivalent:, finds the menu item, fires
[sNativeEventTarget menuItemHit:menuItem] directly, and returns YES.
The responder chain is never consulted; the sheet's text field never
sees the keystroke.
Why Gecko can't compensate from inside menuItemHit: the consumption
happens at the Cocoa layer, before Gecko gets involved. By the time
nsMenuUtilsX::DispatchCommandTo runs, the keyDown is already
reported handled to AppKit. The sheet is a pure Cocoa construct that
Gecko has no awareness of -- it doesn't update Gecko's focus model
when AppKit hands focus to the panel's NSTextField. So cmd_paste
runs against whatever Gecko thinks is focused (the URL bar, a web
text input, or nothing), which is either invisibly wrong or a
no-op, and there is no signal Gecko could return that would cause
AppKit to retry the keystroke against the responder chain.
The fix mirrors the existing menu_copy special case (added in bug
1478347 for the Emoji picker) for the rest of the standard Edit menu
items: undo / redo / cut / paste / delete / selectAll get the
matching NSResponder selector with target=nil. AppKit's
performKeyEquivalent: now walks the responder chain via
tryToPerform:with:, starting from the key window's first responder,
and only returns YES if some responder claims the action. When a
sheet is up, the panel's text field accepts paste: (cut:, undo:, ...)
natively and handles it inline -- including all the macOS plumbing
the responder chain brings with it (Services, Writing Tools, smart
substitutions, validateUserInterfaceItem: against the actual
target). When no responder claims the action,
MacApplicationDelegate gains forwarders that route each selector to
[nsMenuBarX::sNativeEventTarget menuItemHit:], so Gecko content
keeps its existing behaviour.
This also lets AppKit auto-inject the Speech / Substitutions /
Transformations submenus into the Edit menu, since it now sees the
standard selector wiring it expects.
| Assignee | ||
Updated•1 month ago
|
Comment 5•1 month ago
|
||
| bugherder | ||
Updated•1 month ago
|
Description
•