Adds an API to nsIMacDockSupport to allow launching an application bundle and hiding it from the
list of recent applications.
Differential Revision: https://phabricator.services.mozilla.com/D238206
Adds an API to nsIMacDockSupport to allow launching an application bundle and hiding it from the
list of recent applications.
Differential Revision: https://phabricator.services.mozilla.com/D238206
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
Unlike other platforms on macOS if Firefox is already running and an application wants to open a URL
it doesn't use a command line call. Instead the URLs are passed via the NSApplicationDelegate
instance, our implementation of that creates a new nsICommandLine and runs it through the existing
handlers. This entirely skips the startup logic for choosing the default profile and so URLs are
simply opened in whatever profile happens to be running. Not sure what the precise logic is when
multiple profiles are running, it seems like the oldest one wins, not the most recently used one
which is what we want.
Here we intercept the new command line, attempt to guess if we may need to send it to a different
profile and if so do so by using the normal command line approach which will then use the startup
logic to choose the correct profile to use.
One niggle to this is that macOS also automatically focuses the existing instance of Firefox prior
to sending us the URLs which causes us to immediately switch the default profile. This patch
introduces a delay to that so we process the URLs before the default profile can change.
Differential Revision: https://phabricator.services.mozilla.com/D237221
Unlike other platforms on macOS if Firefox is already running and an application wants to open a URL
it doesn't use a command line call. Instead the URLs are passed via the NSApplicationDelegate
instance, our implementation of that creates a new nsICommandLine and runs it through the existing
handlers. This entirely skips the startup logic for choosing the default profile and so URLs are
simply opened in whatever profile happens to be running. Not sure what the precise logic is when
multiple profiles are running, it seems like the oldest one wins, not the most recently used one
which is what we want.
Here we intercept the new command line, attempt to guess if we may need to send it to a different
profile and if so do so by using the normal command line approach which will then use the startup
logic to choose the correct profile to use.
One niggle to this is that macOS also automatically focuses the existing instance of Firefox prior
to sending us the URLs which causes us to immediately switch the default profile. This patch
introduces a delay to that so we process the URLs before the default profile can change.
Differential Revision: https://phabricator.services.mozilla.com/D237221
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
We set the current profile as default whenever a window activates, but we don't add that listener
until after the first window has activated so the default remains the previous profile until you
change window focus. This always sets the default immediately on startup.
Differential Revision: https://phabricator.services.mozilla.com/D234670
A window's icon controller is only held weakly by the widget code and once it is destroyed it
appears to completely remove the taskbar entry for that window. This maintains a strong reference
the the icon controller once created until the window that owns it is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D231089
When displaying the profile selector on startup we cannot use the normal method of launching a
selected profile by simply launching an new instance of Firefox. This would lose all state from
the original process including any passed command line arguments. Instead we must signal back to
nsAppRunner what profile it should launch. We also need to properly shut down the sqlite database
before shutdown begins as our normal hook isn't in place and the process crashes if the database
hasn't been shut down correctly.
Differential Revision: https://phabricator.services.mozilla.com/D229921
When displaying the profile selector on startup we cannot use the normal method of launching a
selected profile by simply launching an new instance of Firefox. This would lose all state from
the original process including any passed command line arguments. Instead we must signal back to
nsAppRunner what profile it should launch. We also need to properly shut down the sqlite database
before shutdown begins as our normal hook isn't in place and the process crashes if the database
hasn't been shut down correctly.
Differential Revision: https://phabricator.services.mozilla.com/D229921
This also stops sharing browser.profiles.enabled and toolkit.profiles.storeID. In the first case
I want to minimise any risk of this preference getting set to false by accident because then a
user loses all of their profiles. In the latter case there is no point storing it in the database,
we already have a backup mechanism for it and if we have lost the storeID we can't load the database
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D228174
This also stops sharing browser.profiles.enabled and toolkit.profiles.storeID. In the first case
I want to minimise any risk of this preference getting set to false by accident because then a
user loses all of their profiles. In the latter case there is no point storing it in the database,
we already have a backup mechanism for it and if we have lost the storeID we can't load the database
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D228174
