Support dynamic changes to native menu contents while the menu is open
Categories
(Core :: Widget: Cocoa, task, P3)
Tracking
()
People
(Reporter: mstange, Assigned: mstange)
References
Details
(Whiteboard: [proton-context-menus][mac:mr1] [proton-uplift])
Attachments
(12 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
The contents of a native (context) menu are determined by the XUL elements inside the <menupopup>
. At the moment, we only synchronize these contents when the menu opens (after the popupshowing event). If any elements are added or removed while the menu is open, this won't be reflected in the native menu until the next opening.
Unfortunately, there is a WebExtension API that requires these changes to work: browser.menus.refresh()
Changing a menu while it's open does not lead to a good user experience; it can display as a flicker, give a sense of instability, and in some cases cause accidental misclicks.
Nevertheless, this API exists and there is a test for it, and supporting it with native menus is possible.
In this bug I'm going to implement support for dynamic changes of open native menus.
Assignee | ||
Comment 2•4 years ago
|
||
Assignee | ||
Comment 3•4 years ago
|
||
This means that it'll happen even if the menu item is not visible. This will make
it possible to make a menu item visible after initial menu construction.
Depends on D112447
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D112448
Assignee | ||
Comment 5•4 years ago
|
||
Depends on D112449
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D112450
Assignee | ||
Comment 7•4 years ago
|
||
Before, we were only calling SetUpIcon if the item was visible during menu
construction on menu opening, but not if the item became visible after menu
opening.
Depends on D112451
Assignee | ||
Comment 8•4 years ago
|
||
This will make a difference once code inside MenuChildChangedVisibility starts
calling IsVisible(). The method name has "Changed" in it, so it should be called
after the change.
Depends on D112452
Assignee | ||
Comment 9•4 years ago
|
||
Depends on D112453
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D112454
Assignee | ||
Comment 11•4 years ago
|
||
Depends on D112455
Assignee | ||
Comment 12•4 years ago
|
||
This makes the WebExtension API menus.refresh() work.
Depends on D112456
Assignee | ||
Comment 13•4 years ago
|
||
This is exercised by one of the subtests of
browser/components/extensions/test/browser/browser_ext_menus_replace_menu.js :
The menu is opened while it's empty, and then the content items are added
asynchronously while the menu is open.
If we try to open an NSMenu with zero NSMenuItems, macOS immediately closes the
menu after opening it. With a placeholder item it stays open as expected.
Depends on D112457
Updated•4 years ago
|
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Comment 15•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/17312473a6d5
https://hg.mozilla.org/mozilla-central/rev/04c8316f671f
https://hg.mozilla.org/mozilla-central/rev/e6fe584b0c8c
https://hg.mozilla.org/mozilla-central/rev/bff1875da8b0
https://hg.mozilla.org/mozilla-central/rev/359a257f20b1
https://hg.mozilla.org/mozilla-central/rev/6c46f730e7bf
https://hg.mozilla.org/mozilla-central/rev/2cd75d5e7509
https://hg.mozilla.org/mozilla-central/rev/9445397a5ab5
https://hg.mozilla.org/mozilla-central/rev/b7186c85ec33
https://hg.mozilla.org/mozilla-central/rev/d0b9c629a807
https://hg.mozilla.org/mozilla-central/rev/a144273d02b0
https://hg.mozilla.org/mozilla-central/rev/a7e2ed98d5e1
Comment 16•4 years ago
|
||
Hey mstange, can we presume this is part of the set of patches that need to have beta uplift requested for MR1?
Assignee | ||
Comment 17•4 years ago
|
||
Definitely. The current plan is to uplift all native menu fixes in one big chunk in bug 1700679, next Monday morning (European time).
Comment 18•4 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/764d560ff23a
https://hg.mozilla.org/releases/mozilla-beta/rev/b9ca957e4eee
https://hg.mozilla.org/releases/mozilla-beta/rev/da94c8b32bc7
https://hg.mozilla.org/releases/mozilla-beta/rev/8d54b54c7c68
https://hg.mozilla.org/releases/mozilla-beta/rev/bfd76aa40aac
https://hg.mozilla.org/releases/mozilla-beta/rev/1bfa71e9eceb
https://hg.mozilla.org/releases/mozilla-beta/rev/6b7a0d5f582c
https://hg.mozilla.org/releases/mozilla-beta/rev/b28c07d949fc
https://hg.mozilla.org/releases/mozilla-beta/rev/445ea75af7fe
https://hg.mozilla.org/releases/mozilla-beta/rev/ffee17049404
https://hg.mozilla.org/releases/mozilla-beta/rev/18136992ec9d
https://hg.mozilla.org/releases/mozilla-beta/rev/63e72af0f6e2
Updated•4 years ago
|
Description
•