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
Two new things here:
1) We append "Private" to the existing shortcut classification if it is likely to be a Private Browsing shortcut. (To help maintain the goal of avoiding I/O this is done by looking at the filename rather than inspecting the shortcut args.)
2) A totally new `is_taskbar_pinned_private` to report whether or not a Private Browsing shortcut is pinned to the Taskbar.
Differential Revision: https://phabricator.services.mozilla.com/D140653
I ended up refactoring the Windows version specific parts into their own functions, which I think makes this a bit nicer to read.
Differential Revision: https://phabricator.services.mozilla.com/D139183
There's some general improvements to CreateShortcut here: writing them out to a log, setting the working directory, allowing the icon to be customized. To support the shortcuts log, I had to restrict how shortcut locations are specified to be a KNOWNFOLDERID -- I couldn't think of any other way to make sure we accurately record them. Notably, this code has been unused since the Site Specific Browsing work was backed out - so there's no existing callers to worry about breaking.
This patch also enhances the pin to taskbar code to automatically create a shortcut if none exist (this is how we'll want things to work for the Private Browsing shortcuts, and it seemed like a generally useful thing to do).
Differential Revision: https://phabricator.services.mozilla.com/D138197
The bulk of this is wiring in a Private Browsing flag in the places that need it, and using some of the recently added WinTaskbar code to grab the correct AUMID. Beyond that, the notable parts are:
* The interface difference between isCurrentAppPinnedToTaskbarAsync and the other changed methods. I was hoping to use the Private Browsing flag everywhere, but doing so in code that run in a separate thread ended up crashing due to the Preferences usage in WinTaskbar (https://searchfox.org/mozilla-central/rev/9d66919569655a8fae9b431550241c058fa85b8a/widget/windows/WinTaskbar.cpp#216)
* The new string for the Private Browsing shortcut. The exact string may change, so it's hardcoded for now.
* Checking the AUMID of shortcuts when looking for a match (to make sure Private Browsing doesn't pick up non-private, and visa versa)
* Some fixes for tests of ShellService.jsm -- I honestly have no idea how these ever passed on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D138196
These new shortcut logs are named with App name + User SID, which should almost certainly be writeable (unless someone manually created one with a different account for some reason).
Differential Revision: https://phabricator.services.mozilla.com/D138195
Since socket process can be launched before `GeckoDependentInitialize`,
we cache the install directory in `InitSignedPolicyRulesToBypassCig`
instead of using `sBinDir`.
This patch moves `GetInstallDirectory` to WinHeaderOnlyUtils.h to reuse
and removes `WinUtils::GetModuleFullPath` that is unused.
Differential Revision: https://phabricator.services.mozilla.com/D133596
`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 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
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
This allows the check from bug 1719189 to be used by the WDBA without
duplication, and keeps it close to the rest of the UserChoice logic.
Differential Revision: https://phabricator.services.mozilla.com/D121559
Also switch to removing the quotes and command-line parameters from the command
string obtained from the registry before comparing it to our path, instead of
*adding* those things to our path, to make the comparison more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D114383
