This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
This is adding in the new Windows 11 only version of taskbar pinning. For the new pinning to work, we need to use limited access feature tokens. Those are going to be made private and aren't included with this change.
This change will compile, and will work if built against the correct limited access feature tokens, as specified in developer local machine config files, but for every other build, the new taskbar pinning won't work and will fall back to the old methods.
I will implement the try / release building machines using the secret limited access feature tokens in a follow-up diff.
Differential Revision: https://phabricator.services.mozilla.com/D205004
As per comments on this diff about getTaskbarTabShortcutPath () I added validation on the C++ side to ensure that the shortcut name passed in can be used as a filename. Tested the changes in the browser console window and confirmed that regular names "abcd" work and confirmed that bad names ("..\\something", ".\\s", ".s", "some?") failed and generated an exception in Javascript.
Differential Revision: https://phabricator.services.mozilla.com/D199590
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
