Stephen A Pohl
77b69c73de
The macOS Profile Manager (toolkit/profile/content/profileSelection.xhtml) and the Create Profile wizard (createProfileWizard.xhtml) are presented very early in startup, before the hidden window is created, and ship with no <menubar> of their own. As a result the system menu bar shows only the auto-populated "Firefox" application menu while either window is up. The wizard can open a native NSOpenPanel sheet via its "Choose Folder..." button and from there a "New Folder" sub-sheet, which is the canonical reproducer for the bug: without a parent <menubar>, the sub-sheet's text field has no key equivalents to invoke, so Cmd+V (and the other Edit menu shortcuts) don't reach the field via the macOS responder chain. This patch: * Adds a `<menubar>` to both windows containing the standard Edit menu items, wrapped in `#ifdef XP_MACOSX` so non-macOS platforms don't gain a visible in-window menu strip. The menubar fragment lives in a new shared include, `toolkit/content/editMenubar.inc.xhtml`, which is consumed by both call sites. It pulls in the existing toolkit `editMenuKeys.inc.xhtml` for the shortcut <key> nodes; each consumer also loads `editMenuOverlay.js` for the matching <command> set. * Marks both xhtml files for preprocessing (`*` prefix in toolkit/profile/jar.mn) so the `#ifdef` / `#include` directives are resolved at packaging time, and adds them to .prettierignore so Prettier doesn't collapse adjacent preprocessor directives. * Adds a `profile-window-menu-edit` Fluent string in toolkit/locales/en-US/toolkit/global/textActions.ftl, co-located with the existing `text-action-*` strings the new menubar already references for its child menu items. The ID names the Edit menu in its profile-window use case, rather than placing it in the `text-action-*` namespace where every sibling string is an action item rather than the menu that contains them. * Updates AppWindow::OnChromeLoaded() in xpfe/appshell/AppWindow.cpp so that native menu loading is no longer indefinitely queued waiting for the hidden window in flows where no hidden window will be created. Without this, the Profile Manager and wizard windows hit OnChromeLoaded with `sWaitingForHiddenWindowToLoadNativeMenus = true` and queue themselves into a list that no one drains until normal startup runs `createHiddenWindow`, which happens only after the Profile Manager dialog returns. The workaround is to check `nsIAppShellService::hasHiddenWindow` at OnChromeLoaded time: if no hidden window exists by then, none is coming, and we can proceed with native menu setup. With this, the wizard's New Folder sub-sheet (and the Profile Manager's own modal sub-prompts, e.g. Rename Profile) get a real parent Edit menu, AppKit's responder chain dispatches Cmd+C/V/X/Z correctly into the sheet's NSText field, and the system menu bar shows the Edit menu while either window is up. Depends on bug 2040844 (the ChildView undo:/redo: overrides) and bug 2040851 (don't mirror the XUL command disabled state to the NSMenuItem for standard Edit menu items) so that the menu-bar shortcuts, not just paste, work and stay enabled inside native sheets. Differential Revision: https://phabricator.services.mozilla.com/D301466
14 lines
752 B
Plaintext
14 lines
752 B
Plaintext
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
toolkit.jar:
|
|
content/mozapps/profile/createProfileWizard.js (content/createProfileWizard.js)
|
|
* content/mozapps/profile/createProfileWizard.xhtml (content/createProfileWizard.xhtml)
|
|
content/mozapps/profile/profileSelection.js (content/profileSelection.js)
|
|
* content/mozapps/profile/profileSelection.xhtml (content/profileSelection.xhtml)
|
|
#ifdef MOZ_BLOCK_PROFILE_DOWNGRADE
|
|
content/mozapps/profile/profileDowngrade.js (content/profileDowngrade.js)
|
|
content/mozapps/profile/profileDowngrade.xhtml (content/profileDowngrade.xhtml)
|
|
#endif
|