The thinking here being that if a previous profile exists, then the
--first-startup argument is probably be passed because the user is
reinstalling on a system that still has (or once had) the browser
already installed on it. In that case, we're going to use that
pre-existing profile, and we don't need to do the FirstStartup
things, since they're primarily for systems where a new profile
is being created after install.
Differential Revision: https://phabricator.services.mozilla.com/D199763
The thinking here being that if a previous profile exists, then the
--first-startup argument is probably be passed because the user is
reinstalling on a system that still has (or once had) the browser
already installed on it. In that case, we're going to use that
pre-existing profile, and we don't need to do the FirstStartup
things, since they're primarily for systems where a new profile
is being created after install.
Differential Revision: https://phabricator.services.mozilla.com/D199763
This commit includes the changes to call into the new asynchronous code to set the browser as default, using powershell.
While here, we add more logging to this interaction to allow easier
debugging with QA.
Differential Revision: https://phabricator.services.mozilla.com/D194949
This commit includes the changes to call into the new asynchronous code to set the browser as default, using powershell.
While here, we add more logging to this interaction to allow easier
debugging with QA.
Differential Revision: https://phabricator.services.mozilla.com/D194949
There's windows-specific code which checks if a profile has been selected
before opening an url in a new window. This code is also useful for macos. It
fixes the bug that opens an empty window if you attempt to click a link before
a profile has been selected.
Differential Revision: https://phabricator.services.mozilla.com/D190988
This commit replaces two existing launch argument keys, `launchURL`
and `privilegedName`, with an opaque string of data. Here opaque
means, "does not need to be inspected by the Windows notification
server DLL" (and in general, by the system backend components).
The existing `action` argument key was always intended for this
purpose but was not used in the first implementation. Here, we make
`action` a stringified JSON object, which is easy for API consumers to
manage and generalizes to (mostly) arbitrary relaunch data.
This JSON object is a compound `notificationData` object containing
both:
- the consumer-provided `opaqueRelaunchData` (generally, an action);
- and implementation-provided details (the alert's name, if
privileged, etc).
This compound object and the fact that everything transits as strings
makes everything a little more confusing than it really is.
The API to this opaque relaunch data is based on strings for
convenience. It would be possible to manage JSON objects, perhaps by
using `nsIStructuredCloneContainer` to serialize "structured clone
encodable" JS objects across the process boundaries, but managing the
objects and container in that approach is much more effort than having
the API consumer stringify as desired.
In addition, this patch makes the notification server extract the
Firefox `action` data from the Windows toast `arguments` passed to the
server callback. Since this fallback data is now provided to Firefox
at launch, there's no need to fetch it from the Windows notification
object; we simply need to know whether to pass through to a Windows
8.1 callback (`tagWasHandled=true`) or to act on the fallback data
(`tagWasHandled=false`). This is simpler than teaching Firefox to
extract the arguments for toast itself or the appropriate action
button.
Differential Revision: https://phabricator.services.mozilla.com/D182314
This goes through the previous changes in the dependencies of bug 877389, and does two things:
1) Remove instances of \n
2) Change reporting of exceptions so that they are passed as separate arguments. This should result
in an improved display of the exception in the browser console, should it occur.
Differential Revision: https://phabricator.services.mozilla.com/D180843
This uses the existing `browser.launched_to_handle ::
system_notification` event. This is expedient and looks ahead to
making the WDBA a background task, where we likely will set the
privileged `name` of the toast to `default-browser-agent` or similar.
The alternative is to add a `browser.launched_to_handle ::
default_browser_agent` event. I started with this and it's simply
duplication. The data analysis phase will look almost identical with
either implementation: it's either filtering on the event name or on
the `name` key in the event extras.
Differential Revision: https://phabricator.services.mozilla.com/D179257
We need to ensure we're not in a `WndProc` callback context when interacting with native notification COM objects, which is currently a problem when called from the command line handler (see Bug 1805802). We achieve this by moving COM work onto a background task which defers processing until after `WndProc` returns.
Now that retrieving the fallback URL occurs on a background task waiting for it before returning would block the main thread. Making `handleWindowsTag` async introduced race conditions with commandline handling, requiring a `enterLastWindowClosingSurvivalArea`/`exitLastWindowClosingSurvivalArea` to prevent misbehavior in case early blank window is pref'd off. In order to simplify exit cleanup, the API was updated to return a `Promise`.
Differential Revision: https://phabricator.services.mozilla.com/D160458
