For whatever reason, in Thunderbird's xpcshell tests, gfxVars was not initialized
when we called this function. It is for firefox. Add in Initialization to fix it.
Differential Revision: https://phabricator.services.mozilla.com/D138944
This change is needed to avoid toolkit/components/backgroundtasks/tests/browser/browser_xpcom_graph_wait.js test failures where the nsUUIDGenerator service was loaded during ASan test runs but not non-ASan test runs (due to differences in temp profile directory paths). With this change, the nsUUIDGenerator service is no longer needed in BackgroundTasks.
Using nsID::GenerateUUIDInPlace() also avoids the overhead of instantiating the nsUUIDGenerator service.
Depends on D136992
Differential Revision: https://phabricator.services.mozilla.com/D136993
Ordinarily, GeckoView apps are not allowed to set the profile folder, which is
always the default one. Furthermore, app's folders (which include the profile
folder) are private to the app and non-root users are not able to access them
or modify them.
For tests, however, we allow setting the profile folder through a special
config file.
If Gecko is not able to access the profile folder (e.g. because the folder was
deleted by the test but the config file is still present), it will error out,
and fire an Alert dialog to let the user know that the profile folder could not
be accessed.
On GeckoView, we cannot handle this Alert dialog as it's not originating from a
Window.
Before this patch, GeckoView would silently exit without giving a reason.
Given the test-only nature of this problem, we just log a statement and return,
so developers can troubleshoot the problem.
Differential Revision: https://phabricator.services.mozilla.com/D136545
Ordinarily, GeckoView apps are not allowed to set the profile folder, which is
always the default one. Furthermore, app's folders (which include the profile
folder) are private to the app and non-root users are not able to access them
or modify them.
For tests, however, we allow setting the profile folder through a special
config file.
If Gecko is not able to access the profile folder (e.g. because the folder was
deleted by the test but the config file is still present), it will error out,
and fire an Alert dialog to let the user know that the profile folder could not
be accessed.
On GeckoView, we cannot handle this Alert dialog as it's not originating from a
Window.
Before this patch, GeckoView would silently exit without giving a reason.
Given the test-only nature of this problem, we just log a statement and return,
so developers can troubleshoot the problem.
Differential Revision: https://phabricator.services.mozilla.com/D136545
Ordinarily, GeckoView apps are not allowed to set the profile folder, which is
always the default one. Furthermore, app's folders (which include the profile
folder) are private to the app and non-root users are not able to access them
or modify them.
For tests, however, we allow setting the profile folder through a special
config file.
If Gecko is not able to access the profile folder (e.g. because the folder was
deleted by the test but the config file is still present), it will error out,
and fire an Alert dialog to let the user know that the profile folder could not
be accessed.
On GeckoView, we cannot handle this Alert dialog as it's not originating from a
Window.
Before this patch, GeckoView would silently exit without giving a reason.
Given the test-only nature of this problem, we just log a statement and return,
so developers can troubleshoot the problem.
Differential Revision: https://phabricator.services.mozilla.com/D136545
There are pros and cons of doing this. Pros are:
* Both Fedora and Ubuntu ship this by default. I haven't run the
numbers but my guess is that with those two distros the amount of
users on Wayland will probably be greater than the amount of users on
XWayland.
* Wayland touchscreen support, and a bunch of other features that
XWayland doesn't have (I'm probably missing a bunch).
Cons that come to mind are:
* The main one is that we're still testing X11 on automation, though it
is my understanding that Martin has Wayland tests running on the
Fedora automation. I'd understand if we'd want to defer this until we
have Wayland tests running on the Mozilla automation (bug 1725245),
though arguably that hasn't stopped us from shipping X11+EGL (though
arguably a smaller change, too).
* I think the other annoyance of Wayland is the lack of proper PiP
support (bug 1621261): Right now users need to right-click on the PiP
Window.
There (most likely) will be others pros and cons (and if we can't come
up with others this patch should allow us to gather more feedback in
Nightly / early-beta). Thoughts?
Differential Revision: https://phabricator.services.mozilla.com/D135456
The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate `pingsender` to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the `backgroundupdate` task (and the test-only
`shouldprocessupdates` task).
Differential Revision: https://phabricator.services.mozilla.com/D133557
I've elected to rename the function from `Should...` to
`ShouldNot...`, but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.
This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133556
The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate `pingsender` to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the `backgroundupdate` task (and the test-only
`shouldprocessupdates` task).
Differential Revision: https://phabricator.services.mozilla.com/D133557
I've elected to rename the function from `Should...` to
`ShouldNot...`, but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.
This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133556
This is required to replace the existing MOZ_FORCE_ENABLE_FISSION environment
variables in environments which use that. In the future we'll want to stop
passing any environment variable when not passing a flag to `./mach run`
however that will require changes to the default test behaviour in bug 1744091.
Differential Revision: https://phabricator.services.mozilla.com/D133006
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
A call to InitCommandLine was added in Bug 1727180 where gArgc and gArgv are
not defined.
The same bug also re-enabled some tests that appeared to pass (but really they
were just silently crashing), this patch fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D130223
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
The product experience migrating a profile when a non-MSIX Firefox is
running is not ideal, so we're going to always start with a fresh
profile for simplicity.
This is a straight backout of the "meat" of Bug 1709969 - Migrate from
an existing profile when running from an app package for the first
time, namely `hg backout -r 5136d2f684012dc3d586dcb10374f8c6eda8b6d7`.
The changes from follow-up Bug 1723298 (correcting test failures on
devedition), namely revision a4bca433c8f7003a90fda61248f38d9b389c394e,
were manually reverted and the test files deleted.
Differential Revision: https://phabricator.services.mozilla.com/D129066