This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Inheriting PerThreadAtomCache on CycleCollectedJSContext permits use of
static_cast, avoiding one level of indirection compared to adding a
CycleCollectedJSContext* to PerThreadAtomCache.
PerThreadAtomCache is over 18kB, and so WorkerJSContext and WorkletJSContext
are moved from the stack to the heap.
MozReview-Commit-ID: 6jdJeZcviK4
--HG--
extra : rebase_source : 3c2accb71faf3f017a44c405ae0484e57aaf039c
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
And a builtin function to test if wasm gc is enabled or not, to make testing
easier.
--HG--
extra : rebase_source : 0e608756d0c5f0231ba31af482c5e343a7119465
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
Our Web Worker code uses a thread pool where a single OS thread can be reused
for different worker scripts during its lifetime. Before this patch, we only
registered these threads with the profiler for the duration that they're
running a worker script. So the same OS thread could be registered with the
profiler during multiple disjoint time ranges, and we would expect the profiler
to treat those different registrations as different conceptual threads.
This had multiple advantages:
- The "thread name" of the conceptual thread can include the script URL:
"DOM Worker <scriptURL>". This allowed you to create thread filter which
match a part of the URL, so you had the option of profiling just the worker
threads you were interested in.
- We wouldn't waste time sampling a worker thread while it's idle and has no
script.
But it also had disadvantages:
- The profiler platform doesn't actually know how to deal with different
"conceptual threads" that share the same OS thread. This lead to surprising
breakage in different places. For example, the contents in the profiler
buffer are marked with ThreadId entries which use the OS thread id.
- What we show in the profiler UI didn't not match reality, and might be
confusing to some people.
I don't think the advantages are large enough to warrant teaching the rest of
the profiler platform to deal with conceptual threads. So this change makes us
stop doing the special thing and just register the OS threads for their entire
duration.
MozReview-Commit-ID: 82RtlRlwy3Y
--HG--
extra : rebase_source : 101e144f17718ea8f05e8bef8200b8ed41ee854e
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'JSGCParamKey'
--HG--
extra : rebase_source : ff972b29f9a89fcbe50d9f105196bcd8f06486bd
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
For the Quatum DOM project, it's better to work in terms of event targets than
threads. This patch converts DOM code to operate on event targets rather than
threads, when possible.
MozReview-Commit-ID: 5FgvpKadUA2
Trackers use navigator.hardwareConcurrency as yet another source of entropy to fingerprint users. The Firefox Hardware Report says 70% of Firefox users have exactly 2 cores. When the privacy.resistFingerprinting pref is set, we want to blend into the crowd so spoof navigator.hardwareConcurrency = 2 to reduce user uniqueness. This pref was added in bug 1345322 for the Tor uplift project.
https://metrics.mozilla.com/firefox-hardware-report/#goto-cpu-and-memory
MozReview-Commit-ID: CDWAaxjRpqe
--HG--
extra : rebase_source : a24eabf1d0b0ea1706478306287634dae38a8c52
NS_SetCurrentThreadName() is added as an alternative to PR_SetCurrentThreadName()
inside libxul. The thread names are collected in the form of crash annotation to
be processed on socorro.
MozReview-Commit-ID: 4RpAWzTuvPs
To run JS in separate cooperative threads, we need to split up per-thread state
from per-runtime state. This patch does that for XPConnect.
MozReview-Commit-ID: 407SlJ7nR6v
Without this change, we will call WorkerPrefChanged if a pref whose name just
_starts_ with the name of one of our WORKER_SIMPLE_PREF prefs changes. Then in
WorkerPrefChanged we will get the value of the pref that changed, and store it
under the key identified by the closure, thus writing the value of an incorrect
pref in there.
MozReview-Commit-ID: JTsvvtC5P1o
Currently, JS sampling has major problems.
- JS sampling is enabled for all JS threads from the thread that runs
locked_profiler_start() -- currently only the main thread -- but the JS
engine can't handle enabling from off-thread, and asserts. This makes
profiling workers impossible in a debug build.
- No JS thread will be JS sampled unless enableJSSampling() is called, but that
only happens in locked_profiler_start(). That means any worker threads
created while the profiler is active won't be JS sampled.
- Only the thread that runs locked_profiler_stop() -- currently only the main
thread -- ever calls disableJSSampling(). This means that worker threads that
start being JS sampled never stop being JS sampled.
This patch fixes these three problems in the following ways.
- locked_profiler_start() now sets a flag in PseudoStack that indicates
JS sampling is desired, but doesn't directly enable it. Instead, the JS
thread polls that flag and enables JS sampling itself when it sees the flag
is set. The polling is done by the interrupt callback. There was already a
flag of this sort (mJSSampling) but the new one is better.
This required adding a call to profiler_js_operation_callback() to the
InterruptCallback() in XPCJSContext.cpp. (In comparison, the
InterruptCallback() in dom/workers/RuntimeService.cpp already had such a
call.)
- RegisterCurrentThread() now requests JS sampling of a JS thread when the
profiler is active, the thread is being profiled, and JS sampling is enabled.
- locked_profiler_stop() now calls stopJSSampling() on all live threads.
The patch makes the following smaller changes as well.
- Renames profiler_js_operation_callback() as profiler_js_interrupt_callback(),
because "interrupt callback" is the standard name (viz.
JS_AddInterruptCallback()).
- Calls js::RegisterContextProfilingEventMarker() with nullptr when stopping
JS sampling, so that ProfilerJSEventMarker won't fire unnecessarily.
- Some minor formatting changes.
--HG--
extra : rebase_source : 372f94c963a9e5b2493389892499b1ca205ebc2f
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
There is a single GeckoSampler and it is currently only accessed on the main
thread, so it's silly to use TLS for it; a normal global variable is better.
This patch also adds main thread assertions to a number of the profiler_*()
functions. Even though bug 1330184 may get rid of some of them, right now they
are a useful as both a sanity check and documentation.
--HG--
extra : rebase_source : 7613eb3cc8089b31180365f6463c81f4556c7b66
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
