Additionally should prevent elevated updates from running at all on a silent restart, since this will always require UI.
Differential Revision: https://phabricator.services.mozilla.com/D123568
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Historically, Android builds would dynamically load the gecko libraries
from the APK, so NS_GRE_BIN_DIR didn't make sense. That however changed
a few years ago, and nowadays, libraries are extracted on installation,
and loaded from a normal path. We can thus make NS_GRE_BIN_DIR valid.
The current logic of deriving from NS_GRE_BIN works on most platforms,
but falls flat on Android, so we derive it from XRE_BinaryPath instead.
Differential Revision: https://phabricator.services.mozilla.com/D121696
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
This patch updates the regex pattern to match data where the module index of
a callstack is -1 or a non-negative integer. -1 is legitimately set in
`CreateJSStackObject` when the frame address is not within any module in the
module list.
If the pattern did not match in debug build, calling `toBoolean()` hit the
assert because `matchResult` was not a boolean but null. This patch fixes
that problem, too.
Differential Revision: https://phabricator.services.mozilla.com/D122020
Bug 1720746 was a test failure in the plugin process with ASan, but bug 1718348
tells us the same problem happens in the content process without ASan.
This patch expands the fix to all sandbox processes.
Differential Revision: https://phabricator.services.mozilla.com/D121814
The call to `RtlGenRandom` delay-loads bcryptPrimitives.dll. The GMP process,
however, cannot load bcryptPrimitives.dll after process launch because its process
token is restricted. This is not a problem normally because bcryptPrimitives.dll
is loaded in early stage when the main thread still has a non-restricted impersonation
token.
With ASan, however, the first call to `RandomUint64` happens in a non-main thread,
and it fails because the thread is not impersonated. We have PreloadLibs to mitigate
this kind of problem, but in this case adding bcryptPrimitives.dll to the list does
not help because the call to `RandomUint64` happens before we load PreloadLibs.
The proposed fix is to explicitly call `RandomUint64` in the main thread before
any call to `RandomUint64` in the process.
Differential Revision: https://phabricator.services.mozilla.com/D121203
If `WAYLAND_DISPLAY` is set but `DISPLAY` is not, we have every reason
to assume that we are in a Wayland-only session. Enable the Wayland
backend unconditionally in this case.
Note: We do not bother to further sanity check the content of the env
variables as these can be considered client setup bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120216
It turns out calling gdk_display_close gets us a rematch of bug 1626536,
so remove the call that was added in bug 1718131, and adjust valgrind
suppressions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D120037
This patch disables the update service as if it were disabled by policy
whenever a package identify is present. User interfaces are treated as if
the updater had not been included in the build, because that prevents any of
our usual update UI from being shown, and in particular ensures that we do not
generate messages about an administrator handling updates, as would normally
happen when disabling updates via policy.
The telemetry environment's update.enabled flag is deliberately left alone in
this patch, because the mere fact of using an app package does not really say
anything about whether the user intends to allow automatic updating or not.
Depends on D114427
Differential Revision: https://phabricator.services.mozilla.com/D114886
This patch disables the update service as if it were disabled by policy
whenever a package identify is present. User interfaces are treated as if
the updater had not been included in the build, because that prevents any of
our usual update UI from being shown, and in particular ensures that we do not
generate messages about an administrator handling updates, as would normally
happen when disabling updates via policy.
The telemetry environment's update.enabled flag is deliberately left alone in
this patch, because the mere fact of using an app package does not really say
anything about whether the user intends to allow automatic updating or not.
Differential Revision: https://phabricator.services.mozilla.com/D114886
In D98108 we added infrastructure to detect infos for DRM devices in
multi GPU setups. We didn't use it for detecting device and vendor IDs
thought, which remained flaky.
Extend the code a little bit, allowing us to reliably get the right
IDs - at least for mesa drivers. This should make our detection
as reliable as it was when using GLX.
This should stop us from showing the following warning in most cases:
`[GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot deduce device`
Differential Revision: https://phabricator.services.mozilla.com/D119666
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
We had the constant `kMaxEvents` which limits the maximum number of loading
events in `UntrustedModulesData`. Because we had a check for the number of
events in `UntrustedModulesData::AddNewLoads` where we already swapped
`UntrustedModulesProcessor::mUnprocessedModuleLoads` with a local variable,
when the array exceeds `kMaxEvents`, we discarded the remaining loading events.
The proposed fix is to check for `kMaxEvents` before swapping the unprocessed
events, so that the remaining events will be processed the next time.
This was caught by the `UntrustedModulesFixture` GTest. This test had
another test bug that it always expected modules were loaded in the main
thread except the predefined known modules. This is not correct because
the same process may have loaded a bunch of modules in the earlier GTests
such as graphics drivers in different threads. This patch includes a fix
for that bug as well.
Differential Revision: https://phabricator.services.mozilla.com/D117433
We had the constant `kMaxEvents` which limits the maximum number of loading
events in `UntrustedModulesData`. Because we had a check for the number of
events in `UntrustedModulesData::AddNewLoads` where we already swapped
`UntrustedModulesProcessor::mUnprocessedModuleLoads` with a local variable,
when the array exceeds `kMaxEvents`, we discarded the remaining loading events.
The proposed fix is to check for `kMaxEvents` before swapping the unprocessed
events, so that the remaining events will be processed the next time.
This was caught by the `UntrustedModulesFixture` GTest. This test had
another test bug that it always expected modules were loaded in the main
thread except the predefined known modules. This is not correct because
the same process may have loaded a bunch of modules in the earlier GTests
such as graphics drivers in different threads. This patch includes a fix
for that bug as well.
Differential Revision: https://phabricator.services.mozilla.com/D117433
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
We currently allow software drivers such as `llvmpipe` to run HW-WR -
in nightly and apparently even in release.
Explicitly make these drivers always use SW-WR instead.
While on it, improve our detection for software drivers in glxtest.
This may become handy for new software drivers such as zink+lavapipe.
Differential Revision: https://phabricator.services.mozilla.com/D116771
Bug 1711610 moved `AvailableMemoryTracker::Init()` from `NS_InitXPCOM` to `XRE_mainRun`,
but it caused memory degradation because `AvailableMemoryTracker` was no longer initialized
in the child processes.
I made that part for `nsAvailableMemoryWatcher` to cache the pref value in the earlier design,
but it's not needed at all in the current design because `nsAvailableMemoryWatcher` loads
a mirror value every time.
This patch reverts `AvailableMemoryTracker::Init()` back to `NS_InitXPCOM`.
Differential Revision: https://phabricator.services.mozilla.com/D116742
After bug 1586236, we use the memory resource notification object to detect a low
memory situation on Windows, which is signaled when the available physical memory
is low. If the available physical memory is low, however, it's possible that there
is still commit space enough for the application to run. In such a situation, we
don't want to make aggressive efforts to reduce memory usage.
This patch makes sure we send the memory pressure event (both New and Ongoing) only
when the available commit space is lower than the threshold value defined by the pref
"browser.low_commit_space_threshold_mb". Its default value is set to 200MB
based on our telemetry data indicating ~60% of OOM crashes with <100MB, ~75% with <300MB.
To use the pref in `nsAvailableMemoryWatcher`, this patch moves the call to
`AvailableMemoryTracker::Init()` to `XRE_mainRun()`. It was in `NS_InitXPCOM`
because the old initialization code hooked APIs and needed to be done while
the process has only one thread (bug 741540). The current `AvailableMemoryTracker`
does not use hooks, so it doesn't have to be initialized that early.
Differential Revision: https://phabricator.services.mozilla.com/D115605
The brower process used WMI to add BIOS Manufacturer and MemoryErrorCorrection
annotations to a crash report. The downside is that calling `IWbemLocator::ConnectServer`
loads all of the registered AMSI modules into the process. As we don't actively use either
of the annotations now, this patch removes WMI code to improve the stability.
Differential Revision: https://phabricator.services.mozilla.com/D115334
Creates nsIUpdateProcessor.serviceRegKeyExists(), which checks for existence the registry key written by the installer that indicates that the current installation can use the Maintenance Service.
The nsIUpdateProcessor interface was chosen because that is the one Update-related xpcom component that is implemented in C++. By implementing this in C++, we can use the existing implementation of CalculateRegistryPathFromFilePath() to do most of the work for us.
Unfortunately, we can't really test this feature without being able to write to HKEY_LOCAL_MACHINE, which we have no good way of doing during testing.
Differential Revision: https://phabricator.services.mozilla.com/D114803
Creates nsIUpdateProcessor.serviceRegKeyExists(), which checks for existence the registry key written by the installer that indicates that the current installation can use the Maintenance Service.
The nsIUpdateProcessor interface was chosen because that is the one Update-related xpcom component that is implemented in C++. By implementing this in C++, we can use the existing implementation of CalculateRegistryPathFromFilePath() to do most of the work for us.
Unfortunately, we can't really test this feature without being able to write to HKEY_LOCAL_MACHINE, which we have no good way of doing during testing.
Differential Revision: https://phabricator.services.mozilla.com/D114803
This fixes the issue for me. I can't think of any problems with doing this
here? However I am not an expert in the remote service. As part of this I also
cover the case where the user encounters the profile lock dialogue and selects
to kill the existing instance of Firefox. This can result in a slow startup in
a similar way as far as I've been able to observe.
Differential Revision: https://phabricator.services.mozilla.com/D113054
Bug 1620118 added a new field `isDependent` in the third-party-module ping
which is calculated in `UntrustedModulesProcessor`. However, bug 1684532
revealed it was not accurate because some third-party applications revert
the import table to the original state immediately after their module was
loaded.
Now that we have a logic to determine `isDependent` in `NtMapViewOfSection`
to automatically block a module injected through the import table, we can
pass that value to the ping and remove the original logic in `UntrustedModulesProcessor`.
Differential Revision: https://phabricator.services.mozilla.com/D112227
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
The Downloader's cleanup function really ought to be asynchronous. The observer for "quit-application" is already asynchronous, so there's no problem there. But really, we ought to be cleaning up each downloader that we use, not just the last one. Which means that the cleanup ought to happen in AUS.stopDownload. So this patch will convert AUS.stopDownload to be asynchronous so that we can properly clean up the downloader from there.
Differential Revision: https://phabricator.services.mozilla.com/D110646
When `--backgroundtask TASK` invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
`Telemetry.ShutdownTime.txt` and the `security_state` directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.
Differential Revision: https://phabricator.services.mozilla.com/D110472
It's very unlikely that this would make a difference, since creating
the service does not immediately look for a profile. But it's also
not clear to me why I originally placed it after the service was
created, and it's not impossible that the service creation would look
for `XRE_PROFILE_PATH` (which is how we communicate the desired
profile to the profile service), so let's create the profile before
the service.
Differential Revision: https://phabricator.services.mozilla.com/D110309
`glXChooseVisual` requires us to choose whether we want single or
double buffered visuals. We don't care here, so check for both
cases.
Differential Revision: https://phabricator.services.mozilla.com/D110540
If a prompt would be required to elevate, set an error update status, which
will be reset by the update service.
Also fix restarting from a background task: keep the --backgroundtask arg
until it can be saved in gRestartArgv.
Differential Revision: https://phabricator.services.mozilla.com/D108899
This commit adds a new command line option |-xpcshell| that, when passed, will
run an xpcshell instead of launching a full Gecko instance.
This command line option is restricted to org.mozilla.geckoview.test for now,
as it's really hard to use and not really a usecase outside mozilla. We can
revisit this if there's interest.
Differential Revision: https://phabricator.services.mozilla.com/D106211
FILE_FLAG_DELETE_ON_CLOSE had the wrong semantics, rendering the lock
file unusable after it had been closed once.
Delete the lock file in the uninstaller as a simple alternative (given that
the lock file is not in a temporary location on Windows).
For a test I returned to the older form of
test_backgroundtask_update_sync_manager which initially exposed the issue:
It expects the background task to be able to detect the xpcshell instance
after running resetLock, which failed before this fix.
I also extended the original updateSyncManager test to run the second
copy twice, which also catches the issue.
Differential Revision: https://phabricator.services.mozilla.com/D109565
This commit adds a new command line option |-xpcshell| that, when passed, will
run an xpcshell instead of launching a full Gecko instance.
This command line option is restricted to org.mozilla.geckoview.test for now,
as it's really hard to use and not really a usecase outside mozilla. We can
revisit this if there's interest.
Differential Revision: https://phabricator.services.mozilla.com/D106211
NativeMenuMac implements a new mozilla::widget::NativeMenu interface.
This interface is intended to be used by cross-platform C++ code.
nsStandaloneNativeMenu is now only used to implement the IDL interface (which
is used from JavaScript code), and C++ code can use NativeMenu with its more
ergonomic C++ interface.
Differential Revision: https://phabricator.services.mozilla.com/D109173
Before this patch, when the profile is locked on Android, we would call "ps",
parse the human-readable output and kill any other Gecko process that we could
find.
But this is completely unnecessary, as we know exactly that the PID of the
process holding the lock is.
In this patch we just kill the process holding the lock since this is
equivalent to the previous behavior.
Differential Revision: https://phabricator.services.mozilla.com/D106186
Backend procedure gdk_{x11,wayland}_display_make_default() gets called twice by XREMain::XRE_mainStartup(). First time it gets called indirectly after a call to gdk_display_open() because GDK automatically chooses first opened display as default display and calls gdk_{x11,wayland}_display_make_default() accordingly. Second time it gets called directly as a backend for an excessive call to gdk_display_manager_set_default_display(). Two consecutive calls to gdk_{x11,wayland}_display_make_default() trigger a bug in GTK <= 3.24.7 which causes content of DESKTOP_STARTUP_ID environment variable to get lost (GTK Bug 790963). In the absence of this information, startup notification can't be properly sent back to the environment when GTK later displays the main window.
Differential Revision: https://phabricator.services.mozilla.com/D108314
Fission without WebRender is an unsupported configuration and enrolls
users based on their compositor. However because of our own rollout of
WebRender, a user might start in early beta with WebRender and lose it
in late beta, while they remain enrolled in the Fission experiment.
Also, a user could lose WebRender because of crashes or device reset,
and we may fall back to Basic.
This patch forces Software WebRender as available (but does not override
Hardware WebRender) if Fission is enabled for users enrolled in the
Fission experiment. It also prevents fallback to Basic layers when
disabling acceleration due to crashes and runtime errors, so the user
will be stuck with Software WebRender at a minimum. It also enables
Software WebRender for Windows popups with transparency.
Differential Revision: https://phabricator.services.mozilla.com/D107661
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
This commit does three main things:
1) It allows to configure the global singleton `nsUpdateSyncManager`
with an `nsIFile` rather than having it use the ambient XPCOM
directory service. This allows to initialize the
`nsUpdateSyncManager` very early: before processing updates and long
before XPCOM is initialized. This in turn allows us to determine if
other instances early enough to skip processing updates when
appropriate.
When this initialization path is followed, i.e., in Firefox but not
`xpcshell`, the `xpcom-startup` notification will be received but no
action taken, since the singleton will already exist.
There is a classic time-of-check, time-of-use race window in this
implementation: an instance may be launched immediately after we check
for other instances. In practice this will result in behaviour that
is alreay possible: two independent instances both processing updates.
It is expected that the updater itself will exclude one of the
instances using its existing mutex.
2) It updates an existing background task test to use an explicit
`nsIFile` rather than the existing directory service method. This
exercises the newer API. There are other tests that might benefit,
but there's no harm in remaining with the previous approach, since
both are required.
3) It adds a new background task test to verify that update processing
is skipped if we're not the sole instance running.
Differential Revision: https://phabricator.services.mozilla.com/D106994
This commit does three main things:
1) It allows to configure the global singleton `nsUpdateSyncManager`
with an `nsIFile` rather than having it use the ambient XPCOM
directory service. This allows to initialize the
`nsUpdateSyncManager` very early: before processing updates and long
before XPCOM is initialized. This in turn allows us to determine if
other instances early enough to skip processing updates when
appropriate.
When this initialization path is followed, i.e., in Firefox but not
`xpcshell`, the `xpcom-startup` notification will be received but no
action taken, since the singleton will already exist.
There is a classic time-of-check, time-of-use race window in this
implementation: an instance may be launched immediately after we check
for other instances. In practice this will result in behaviour that
is alreay possible: two independent instances both processing updates.
It is expected that the updater itself will exclude one of the
instances using its existing mutex.
To avoid the race, we could take the exclusive multi-instance lock
ourselves, but that is strictly more complicated.
2) It updates an existing background task test to use an explicit
`nsIFile` rather than the existing directory service method. This
exercises the newer API. There are other tests that might benefit,
but there's no harm in remaining with the previous approach, since
both are required.
3) It adds a new background task test to verify that update processing
is skipped if we're not the sole instance running.
Differential Revision: https://phabricator.services.mozilla.com/D106994
This implements the simple approach advocated for in
https://bugzilla.mozilla.org/show_bug.cgi?id=1120863#c26.
It's not easy to lift the duplicated chrome document URL to a shared
location, so we instead annotate both locations.
I've provided an environment variable that will allow a process that did
not itself process updates to witness that fact and used it to add a test.
Differential Revision: https://phabricator.services.mozilla.com/D106993
Inversed logic has been proven to be more difficult to read,
so use the simple positive variant.
Also add a simple sanity check for `WAYLAND_DISPLAY` so if people
set `MOZ_ENABLE_WAYLAND` in a X11 session don't get undesired behavior.
While on it, change a check for `XDG_SESSION_TYPE` to also use
`WAYLAND_DISPLAY`, improving behavior when launching FF from a TTY
or a TTY-launched session (e.g. via `weston-launch`).
`WAYLAND_DISPLAY` and `DISPLAY` are not expected to be set if
no Wayland or X11 server is available, so using them makes us behave
more predictable.
Differential Revision: https://phabricator.services.mozilla.com/D106726
Triggering the password prompt after the Add-Ons Manager start-up is causing the latter to fail.
I'm not sure if something needs to be unlocked by the password, or if the existence of the prompt is causing some bad interaction, but prompting slightly earlier appears to fix it.
Differential Revision: https://phabricator.services.mozilla.com/D106382
GetValue is going to be removed in a subsequent patch. It is no longer needed,
because it can be replaced by functions already provided by nsBaseHashtable,
in particular Lookup and Contains.
Also, its name was confusing, since it specifically returns a pointer that
allows and is intended for modifying the entry within the hashtable, rather
than returning by-value. According to the naming rules to be set on
nsBaseHashtable, it would also needed to be renamed to "Lookup*. Removing
its uses saves this effort.
Differential Revision: https://phabricator.services.mozilla.com/D105476
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
A. The shell provides the startup shortcut in STARTUPINFOW when it
starts a process. If the launcher process runs, we must pass this along
to the real process being created.
B. lpTitle can be overwritten, in particular when the AUMID is set for
WinTaskbar, so save it in XREMain::XRE_mainStartup() in order to access
it later.
C. Add an accessor for the saved shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D106343
We know that some GV installations (particularly but not exlcusively Focus) are
failing to load `libxul.so` during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.
This patch adds `mozilla::Result`-based return values to `XPCOMGlueLoad` and
`GetBootstrap` in an effort to produce more actionable information about these
failures.
We include either a `nsresult` or, if the failure is rooted in a dynamic linker
failure, appropriate platform-specific error information:
* On Unix-based platforms, a `UniqueFreePtr<char>` containing the string from `dlerror(3)`;
* On Windows, the Win32 `DWORD` error code from `GetLastError()`.
For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.
For Android, we include the error information in the message string that we pass
into the Java `Exception` that is subsequently thrown.
Differential Revision: https://phabricator.services.mozilla.com/D104263
Kirk
Markus Stange
Jonathan Watt
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Kagami Sascha Rosylight
Iulian Moraru
Nicklas Boman
Mike Hommey
Aaron Klotz
Alexandru Michis
stransky
Alexandre Lissy
Toshihito Kikuchi
Gabriele Svelto
Sandor Molnar
Adam Gashlin
Molly Howell
Robert Mader
Csoregi Natalia
Doug Thayer
Narcis Beleuzu
Dorel Luca
Kris Maglione
Youhai Li
Brindusan Cristian
Nika Layzell
Glenn Watson
Magnus Melin
Cosmin Sabou
Jonathan Kew
Butkovits Atila
David Parks
Nick Alexander
Agi Sferro
Emilio Cobos Álvarez
Simon Giesecke
Florian Quèze
Dave Townsend
Oleg Strikov
Andrew Osmond
Jan Alexander Steffens (heftig)
Geoff Lankow
Olli Pettay
Horst
Jens Stutte
Alexis Beingessner
Paul Bone