In addition to moving these methods to a more appropriate file, they were
simplified to make them easier to maintain in the future.
nsTStringRepr::Compare was extended to also work on char16_t strings, and the
case insensitive and other options were removed as they aren't necessary. This
required some changes to callers in the tree.
The EqualsIgnoreCase method was also simplified by using `std::string_view`.
Differential Revision: https://phabricator.services.mozilla.com/D148299
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This verifies that stale temporary profile purging does not interfere
with concurrent temporary profile creation and locking.
Depends on D144775
Differential Revision: https://phabricator.services.mozilla.com/D144328
That is, treat it as a hint if called before open, and as an override if
called after. Override the hint on open.
This is a less invasive change that is green on try and also fixes the
issue.
Differential Revision: https://phabricator.services.mozilla.com/D145098
There are a few ways that we could test this. We could use the
profiler and "File IO" markers, a la
https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_startup_content_mainthreadio.js.
This would profile content that is transient, which could be good or
bad -- temporary files for atomic writes would show up for example.
But in fact there are profile contents created after the profiler is
shut down (including `Telemetry.ShutdownTime.txt`), so this approach
isn't sufficient.
Therefore we do the simpler thing: we simply don't remove the
temporary profile directory after the background task exits.
Differential Revision: https://phabricator.services.mozilla.com/D139909
This version is as simple as I can make it. It simply expects the JS
debugger to stop on the breakpoint added automatically by the
backgroundtask debugger command line processing (using
`setBreakpointOnLoad`) and disconnects, expecting the task to continue
execution and exit with exit code 0.
In the future, we'd like to interact with the task environment, for example to:
1. stop on the automatic breakpoint
2. continue
3. stop on a `debugger;`
4. set the task's exit code from a failure code to exit code 0
5. continue
6. verifies the tasks's exit code is 0.
Sadly my attempts to do this fail intermittently in automation.
Differential Revision: https://phabricator.services.mozilla.com/D139156
Background task mode is roughly equivalent to `xpcshell`, but inside
the regular browser startup flow. There is no browser window (no
`Window` at all) and there should be no content processes. It's
sufficient to treat it like `xpcshell`, with its own stripped-down
actor and a few tweaks to the integration points.
The structural changes in this commit keep `--backgroundtask` mode
slim in the regular case when the Devtools are *not* requested. This
is reflected in the small changes needed to the
`browser_xpcom_graph_wait.js` test: loading the Devtools
unconditionally causes a huge amount of code to be loaded. In order
to load the Devtools framework conditionally, we check for
Devtools-specific command line flags and delegate to Devtools when
appropriate. In order to check the command line flags, we turn the
`BackgroundTasksManager` into an XPCOM service, which allows it to be
instantiated by XPCOM in order to handle the command line.
One final note: this leaves two XPCOM components, "backgroundtasks"
and "backgroundtasksmanager". Why not combine them? This is
technically possible but not attractive: we really do want a natural
place for native/C++ code ("backgroundtasks") and JavaScript code
("backgroundtasksmanager").
Differential Revision: https://phabricator.services.mozilla.com/D129771
Other cleanup:
* Remove unused headers and replaced with forward declarations where possible.
* Removed redundant `mozilla::` namespacing for individual variables.
* Resolved clang-tidy warnings for unnecessary use of `const` return and suggested use of move semantics.
Differential Revision: https://phabricator.services.mozilla.com/D139328
We may get multiple lines or incomplete lines from the pipe, so we
need to split the data and keep the leftover. This makes debugging a
little more pleasant and allows for the consumer to react to stdout as
it is read.
Differential Revision: https://phabricator.services.mozilla.com/D138222
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
Once we allow lazy initialization for the permission manager, we do not launch it at startup in any kind of process. We thus need to update the allowlist of this test and remove the permission manager and other (networking) modules it started.
Differential Revision: https://phabricator.services.mozilla.com/D133655
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
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
