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
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 does two things. First, it expects the special
FirefoxPDF-... ProgID to be available for UserChoice. We could manage
without it for a while, but eventually we expect set-to-default to
include PDFs. When that is the case, if it doesn't exist, something
has gone very wrong, and we'd like to find that out (via our existing
telemetry, which reports "missing" ProgIDs).
Second, it arranges to use the new FirefoxPDF-... ProgID when
setting-to-default.
Differential Revision: https://phabricator.services.mozilla.com/D142303
When enabled, this feature restricts the existing
`setDefaultPDFHandler` Nimbus feature to only set Firefox as the
default PDF handler when the existing handler is a known browser.
Depends on D142147
Differential Revision: https://phabricator.services.mozilla.com/D142148
`HeadlessShell.handleCmdLineArgs` needs to skip arguments starting with a hyphen
to search for a URL.
This patch also fixes a problem that `nsNativeAppSupportWin::CheckConsole` did
not remove processed command options.
Differential Revision: https://phabricator.services.mozilla.com/D132987
This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
This adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
This adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
This adds a `setDefaultPDFHandler` that extends the existing
`setDefaultBrowserUserChoice` to also set Firefox as the default PDF
handler when setting Firefox as the default browser. (Since this uses
User Choice, it's Windows 10+ only.)
Differential Revision: https://phabricator.services.mozilla.com/D132660
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
