Gfx blocklist doesn't actually use the desktop environment filter so
remove that functionality. We can reintroduce it in the future if we
need it.
Differential Revision: https://phabricator.services.mozilla.com/D166090
I was unable to get gnome searching working at all on my machine (perhaps it's broken on Ubuntu?), thus I was unable to verify this fix myself -- but it seems pretty straightforward and safe to take.
Differential Revision: https://phabricator.services.mozilla.com/D164902
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
The current shortcut detection was good enough for a long while -- it was mainly used for Telemetry purposes, and installer created shortcuts were almost always created anyways -- so both the rate of mismatches and the consequences of them were fairly low. This changed when we implemented Private taskbar pinning, most notably because when we're creating Private Browsing shortcuts in the installer (which we ought to do to work around various Windows bugs), we end up with 2 strings for the shortcut names (one for the installer, one for the browser).
The other thing that has changed since this was originally implemented is that all of those code has moved off of the main thread -- so it is less perf-sensitive than it was before.
With these two things in mind, making our shortcut detection much more accurate seems like the right thing to do. There's still rare cases (noted in the original comments) where it could be wrong -- but with this change we no longer rely on the file name, which can very easily be wrong for a number of reasons.
This also includes a fix for a bug I introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1789974 that caused pinning not to work if a shortcut needed to be created at pinning time (unlikely except in zip builds, but still needs to be fixed).
Differential Revision: https://phabricator.services.mozilla.com/D158799
It turns out that the INI parser used by NSIS only supports UTF-16LE encoding. Our INI parser doesn't support UTF-16 at all, so we need to a bit of work ourselves to write this file correctly.
Differential Revision: https://phabricator.services.mozilla.com/D157378
In the recent refactor of this (https://bugzilla.mozilla.org/show_bug.cgi?id=1782295) I managed to break our ability to create shortcuts if they don't already existed. This was caused by two things:
1) An errant `NS_SUCCEEDED` call remained after the call it was checking moved elsewhere (oops)
2) The taskbar pinning code was not updated to set the shortcut file path (required after the refactor).
This patches fixes both of those issues. Note that all the directory service interaction is done on the main thread, because the actual function doing the work is on a background thread, and the directory service does not work there.
Differential Revision: https://phabricator.services.mozilla.com/D156993
This was an oversight during the original implementation in bug 1761291. I updated the code that creates shortcuts there, but not the code that looks at existing ones.
Differential Revision: https://phabricator.services.mozilla.com/D156992
In days of old, it was safe to use -brand-short-name for this, as it always lined up with the installer's concept of BrandShortName. This changed when https://bugzilla.mozilla.org/show_bug.cgi?id=1378834 landed -- which started using "Firefox Nightly" for the nightly branding BrandShortName in the installer (but maintained "Nightly" as the in-product -brand-short-name). Changing one or the other of these is not really a viable option:
- Changing the installer's BrandShortName for Nightly to match -brand-short-name would cause shortcuts to simply be called "Nightly" -- which is the opposite of what the aforementioned bug wanted
- Changing -brand-short-name would cause a number of in-product strings to start using "Firefox Nightly" instead of "Nightly" -- which is probably undesirable for a few reasons, not the least of which is possible l10n implications
For these reasons, and the relatively short timeline I have to fix this, I'm taking the simplest and easiest path of introducing a new string specifically for in-product shortcut names, which lines up with the installer's values for BrandShortName. (We perhaps should also separate this out in the installer -- but it's unnecessary here, so I did not go to the trouble.)
Differential Revision: https://phabricator.services.mozilla.com/D156991
This happens during lazy startup, and we try to avoid any main thread I/O there. Even though this will only ever happen once, there's really no reason I know of to keep it on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D155598
This happens during lazy startup, and we try to avoid any main thread I/O there. Even though this will only ever happen once, there's really no reason I know of to keep it on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D155598
In an ideal world we'd pass in the `privateBrowsing` flag and use that to both find the correct AUMID and binary to compare against, but because this code runs off main thread, and finding AUMIDs requires prefs access - we must pass in the AUMID from elsewhere.
Given that, checking that the target of the shortcut is one of the two possible Firefox entry points, and ensuring it matches the requested AUMID, seems reasonable.
There's no technical reason why we couldn't pass in the `privateBrowsing` flag to use in determining which binary we're looking for -- but I don't think it really adds any real benefit, and passing both it an the AUMID makes the interface more confusing.
Differential Revision: https://phabricator.services.mozilla.com/D155008
This fixes a bug where pinning a Private Browsing window to Taskbar with the windows context menu item pins regular Firefox instead. This happens because Windows cannot find an appropriate shortcut (presumably by looking for one with the right AUMID), and ends up creating its own instead -- with almost entirely incorrect metadata.
With this, we'll be creating one at a few points (if it doesn't already exist):
* Installer - for new installs
* Post-Update - to make sure we get one when people update to the first version where we pref this on
* Startup idle - for zip installs, and to handle any other possible case where the shortcut doesn't exist
Until we enable separation of Private Windows by default I've pref'ed off this behaviour (otherwise a user may pin the shortcut to the Taskbar, but the app will launch into a different icon).
Differential Revision: https://phabricator.services.mozilla.com/D147702
The shortcut creation code was mapping the "StartMenu" known folder to what is actually a "Programs" folder. This patch fixes that, and updates some related code to match. Notably, no behaviour has changed (ie: we still create shortcuts in the same place) -- this just makes it more obvious what's happening.
Differential Revision: https://phabricator.services.mozilla.com/D147701
Previously `nsIWindowsShellService::{Check,}PinCurrrentAppToTaskbar` was doing
main thread IO. They have been replaced with async versions that do their work
on a background thread.
Differential Revision: https://phabricator.services.mozilla.com/D145244
`nsIWindowsShellService::CheckPinCurrentAppToTaskbar` does IO which we want to
move off of the main thread. There is now an async version,
`CheckPinCurrentAppToTaskbarAsync`, that runs the IO on a background thread and
returns a promise, which we now use in ShellService.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D145244
