0f61b77b68
Bug 1805414 will move menu event handling to the DOM. With that change the current synthetic click behavior of XUL menuitems breaks. On current central, we rely on nsMenuFrame::HandleEvent not getting called at all for synthetic clicks, and instead we just fire a command event synchronously here: https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071 After my patch the command event is fired properly (potentially asynchronously too) by the regular menu activation machinery, which is preferable. * They fire a command event synchronously (even though on some platforms like macOS activating a context menu item is async). * They use a totally different codepath from what a user does. * They don't deal with native menus, etc. We have a proper API for this (activateItem) which takes a much more closer codepath to what users do, requires that the menu is shown, etc. Use that API instead for testing. As a benefit, tests now do not need to close the context menu manually when clicking on a menu item (because we trigger the same code path as users clicking the menu). Differential Revision: https://phabricator.services.mozilla.com/D164567
This is the PDF.js project output, https://github.com/mozilla/pdf.js The current upstream commit is documented in the revision field in moz.yaml To update PDF.js locally, run ./mach vendor toolkit/components/pdfjs/moz.yaml To avoid cloning PDF.js locally for every invocation of that command, you can point ./mach vendor at a local repo by setting the PDFJS_CHECKOUT env var. The update process will perform a git fetch and checkout the latest version to update to, so any uncommited local changes will cause the update script to break.