This patch adds an additional reference count to each FencesHolder
stored in the map, so that TextureHosts can acquire a reference at
initialization and release it at destruction. Previously the lifetime of
the entry was controlled by the TextureClient + TextureData.
Differential Revision: https://phabricator.services.mozilla.com/D255536
The sandbox has code to handle `socketcall`, a multiplexer for
socket-related syscalls used in Linux's oldest target architectures, by
unpacking the arguments and resubmitting the call using the individual
syscalls added in kernel 4.3 if available. This allows seccomp-bpf to
filter the syscall arguments, and not just which call it is (see also
bug 1066750).
Currently this is a special case for `socketpair` and `getsockopt`; this
patch generalizes it and adds a number of other socket calls, which will
be used by the next patch.
Original Revision: https://phabricator.services.mozilla.com/D255741
Differential Revision: https://phabricator.services.mozilla.com/D259014
If a `find_objects` implementation encounters an error, it may release a
`ThreadSpecificHandles` on the background thread. Before this patch, this would
cause `ThreadSpecificHandles::drop` to block on the currently-running thread,
causing a deadlock. This patch changes the drop implementation to first check
if it's already on the background thread, in which case it can simply release
the resources without blocking on anything.
Original Revision: https://phabricator.services.mozilla.com/D258085
Differential Revision: https://phabricator.services.mozilla.com/D258729
This tests both @import and regular declarations. Without this fix, the test
page renders blue, rather than a blue background with a purple square inside
and a smaller lime square inside.
Differential Revision: https://phabricator.services.mozilla.com/D258293
In the future if we need to we can hook these up to telemetry (in fact it's not
hard, we just need to do that in Document::ReportUseCounters).
For now I want to start using them to record whether we might have a data URI.
Differential Revision: https://phabricator.services.mozilla.com/D258291
No behavior change, but this is simpler. I want to reuse the use
counters mechanism to fix this bug because it's a very trivial way of
asking questions about the parsed data and we need to plumb it through
the same places.
Differential Revision: https://phabricator.services.mozilla.com/D258290
WorkerPrivate's GlobalScope is created during CompileScriptRunnable::WorkerRun.
However, the creation could fail when there is an OOM issue during the WebIDL bindings.
Although the Worker will start the shutdown as soon as possible, there is still a chance that some WorkerRunnable had already been dispatched to the Worker. And there is no guarantee that there is a GlobalScope for the WorkerRunnable.
Unfortunately, WorkerRunnable should check the GlobalScope existence by itself, because not every WorkerRunnable needs the GlobalScope to perform its functionality.
This patch only does the null checking for the ServiceWorkerOpRunnable, since ServiceWorkerOpRunnable are supposed to dispatching an event to the corresponding ServiceWorkerGlobalScope.
Original Revision: https://phabricator.services.mozilla.com/D254659
Differential Revision: https://phabricator.services.mozilla.com/D258725
This allows us to shut down the IAudioSessionManager after Cubeb has stopped,
so there shouldn't be STA apartment deadlock issues with it.
IAudioSessionManager's shutdown always requires the STA. This patch eliminates
MTA threads involvement at shutdown, which was previously needed for thread
safety. We keep other operations on MTA (background) threads, for performance.
This also removes a lot of unused functionality. AudioSession hasn't been
needed outside of the parent process since audio remoting landed.
Differential Revision: https://phabricator.services.mozilla.com/D251773
Previously if one result was the most restrictive possible (verdict=VERDICT_DANGEROUS
and shouldBlock=true), we would not wait for the other result and just use that one.
However, safebrowsing results are generally overridable by the user, but a BLOCK result
from content analysis should not be overridable.
Instead of making the early result check more complicated, I think it's more
straightforward to just always wait for both. The existing hasMostRestrictiveResult()
method already knows that content analysis results should take precedence, and I
renamed the parameters to make that more clear.
Original Revision: https://phabricator.services.mozilla.com/D255389
Differential Revision: https://phabricator.services.mozilla.com/D258223
If the DLP agent responds with WARN for a file, and the user quits Firefox
(after a confirmation dialog), we treat that as a block. Previously we
were just reporting that to the agent and deleting the file on disk. But
for safebrowsing, downloads that were blocked don't persist after a browser
restart, so we should do that too for DLP ones.
So we just delete the download, which includes a call to respond to the
DLP agent and finalize the download, but also removes it from the relevant
lists.
Original Revision: https://phabricator.services.mozilla.com/D255212
Differential Revision: https://phabricator.services.mozilla.com/D258222
I looked into using gInitialPages instead of hard-coding "about:blank",
but:
- there's no convenient window or browser here to access gInitialPages
- We hard-code "about:blank" many other places in source, so its
"specialness" is already pretty well established.
Original Revision: https://phabricator.services.mozilla.com/D254871
Differential Revision: https://phabricator.services.mozilla.com/D258221
Records the action returned in a response from the DLP agent, as well
as how long the agent took to return a response (roughly). Note that if
the agent pops up some kind of its own WARN dialog, the timing recorded
will include how long it took for the user to pick an option, so this
may not end up being too valuable.
Also includes a bit more shuffling around of test code so the telemetry
tests can use it.
Original Revision: https://phabricator.services.mozilla.com/D252574
Differential Revision: https://phabricator.services.mozilla.com/D258218
Records connection attempts, retries, and failures (with nsresult).
This also adds a GetCreatingClientForTest() method so that tests can
call to create a client, then SpinEventLoopUntil() until
GetCreatingClientForTest() returns false, and after this point the
telemetry should be recorded.
Also moves some test code from TestContentAnalysis.cpp to
TestContentAnalysisUtils.h so it can be used in the new telemetry gtests.
Note that these new gtests start the agent every time it's needed - this
will be cleaned up in part 4.
Original Revision: https://phabricator.services.mozilla.com/D252571
Differential Revision: https://phabricator.services.mozilla.com/D258215
Records telemetry for the settings used with Content Analysis. Note
that there is no way in C++ to get the default value of a pref that was
set via an Enterprise Policy (with setAndLockPref()) because that method
actually sets the default value, so I had to modify some of my plans for
telemetry to gather. For example, I was going to record interception points
whose Enabled value differed from the default, but instead we record
any interception points whose Enabled value is false. (right now these
are equivalent, but Downloads will be default-off so this will change)
For the allow/deny URL lists I didn't want to record the actual URLs
on those lists, so we really do want to just record whether the values
are different from the default. I hard-coded the default into
ContentAnalysis.cpp, and we can rely on the JS test
test_ca_enterprise_config_with_default_prefs_telemetry() to start failing
if that changes.
Also adds a forceRecreateClientForTest() method to ContentAnalysis that
tests can use to force trying to connect to a client. (since this is when
we record the settings telemetry)
Original Revision: https://phabricator.services.mozilla.com/D252570
Differential Revision: https://phabricator.services.mozilla.com/D258214
