The clones appear to be so that access for the tree view in preferences is quick. However, they don't need to clone the entire engine object - they just need three fields.
Additionally, this fixes reloading icons which was attempting to use 'uri' but that isn't defined, and so icons would fail to load if preferences was opened when a search engine is added.
Differential Revision: https://phabricator.services.mozilla.com/D80496
This patch additionally makes the search cache responsible for listening to notifications rather than being directly told by the search service to write the cache.
It also makes writes after init/reinit/maybeReloadEngines into delayed writes as they don't need to be immediate - the code already ensures we write any pending cache before reading, and that we write it before shutdown. Therefore, it doesn't matter if we wait a second or so.
Differential Revision: https://phabricator.services.mozilla.com/D80472
Right now setup_perftest_test_date adds --test-date yesterday to all perftest
runs. we want that only for the ones doing batches
Differential Revision: https://phabricator.services.mozilla.com/D81562
Right now, now matter which SafeBrowsing protocol we use (V2 or V4), we
always use variable-length prefix set to store prefixes. Since
nsUrlClassifierPrefixSet is a member of VariableLengthPrefixSet and it
is never used alone, we can remove nsIMemoryReporter from it to prevent
calculating the same memory report twice.
Differential Revision: https://phabricator.services.mozilla.com/D81171
The first try-catch in the test now terminates control flow after the previous patch
and we then ilooped because inIon() never returned true in the loops after that
(these loops are only reachable through the catch-block).
The patch splits the test in a few different functions to fix this.
Depends on D81029
Differential Revision: https://phabricator.services.mozilla.com/D81030
The analysis marked code after a try-catch as always-reachable to simplify MIR
building. Now that we compute reachability of LoopHeads, there's not a lot we gain
from that complexity anymore.
We can then also remove the MGotoWithFake code and the JSOp::Try bytecode operand.
Depends on D80876
Differential Revision: https://phabricator.services.mozilla.com/D81029
Make BytecodeAnalysis determine whether code is reachable only through
catch/finally blocks.
The abort in IonBuilder can then be turned into an assertion. This helps
WarpBuilder because we don't want any non-OOM aborts during MIR building.
Differential Revision: https://phabricator.services.mozilla.com/D80876
We now crash instead of silently using an offset of 0 (meaning start of the
IonScript's JIT code) for the OSR entry point if the MOsrEntry is missing
for some reason.
Differential Revision: https://phabricator.services.mozilla.com/D80874
Some profile meta information can be gathered before the profiler mutex must be locked.
This reduces the main-thread locking when capturing.
Most importantly, it prevents deadlocking in case any of the data-gathering operation would itself rely on profiler-locking functions (e.g., starting a thread, which requires the lock to register the new thread with the profiler).
Differential Revision: https://phabricator.services.mozilla.com/D81491
Allows to remove the dance around the compositor thread just to perform the assertion.
The use of an in-line lambda avoid all ambiguity on which thread this is called.
Differential Revision: https://phabricator.services.mozilla.com/D80635
There's a small race that can happen when the remote decoder gets shutdown during xpcom shutdown; that would cause GetCurrentSerialEventTarget to return null. Leading to an assertion failure in ActorLifecycleProxy thread-safety check when PRemoteDecoderManagerParent gets destroyed.
So we use a background taskqueue instead and cleanup a bit the threading code in there allowed thanks to the TaskQueue ability to not require an explicit shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D81287
NS_INLINE_DECL_REFCOUNTING macro doesn't properly work when the object is used on a thread that isn't backed by a single PRThread (such as TaskQueue). See bug 1648031.
The resolution of this issue is rather complex, and outside the scope of this series of change.
So for now, we create a new macro NS_INLINE_DECL_REFCOUNTING_ONEVENTTHREAD which will use a different mechanism to ensure the thread-safe usage of a class.
Differential Revision: https://phabricator.services.mozilla.com/D81269