This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
In most situations, JSONWriter users already know string lengths (either directly, or through `nsCString` and friends), so we should keep this information through JSONWriter and not recompute it again.
This also allows using JSONWriter with sub-strings (e.g., from a bigger buffer), without having to create null-terminated strings.
Public JSONWriter functions have overloads that accept literal strings.
Differential Revision: https://phabricator.services.mozilla.com/D86192
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
This commit remove the following preferences, which have been
disabled since Firefox 70:
- mathml.nonzero_unitless_lengths.disabled
- mathml.legacy_number_syntax.disabled
These are edge syntaxes for MathML3 lengths that don't align well
with CSS and we haven't received any bug report about it since they
were disabled. Tests are updated to treat attributes using such
values as invalid.
update tests
Differential Revision: https://phabricator.services.mozilla.com/D89920
This [0] commit unties the device selection from the fact that a stream
transports voice data. Telling cubeb that the stream has voice data allows
lowering the complexity of the resampler, and lowering the impact of the
resampler on the latency.
[0]: ac3569ef18
Differential Revision: https://phabricator.services.mozilla.com/D89591
Add 3 probes
- Play time for encrypted elements.
- Play time for Clearkey elements.
- Play time for Widevine elements.
Differential Revision: https://phabricator.services.mozilla.com/D88895
See the bug for the complications that made me write this slightly hacky
fix... Other solutions definitely welcome.
Add a test, adjusted so it would fail without the change.
Differential Revision: https://phabricator.services.mozilla.com/D89835
Prior to this patch, RequestProcInfo attempts to examine all processes from mozilla::ipc::GeckoChildProcessHost::GetAll callbacks.
This causes two issues:
- lifetime management for raw `ContentProcess*` used during the callbacks works but is complicated to audit;
- for each `GeckoChildProcessHost` identified as a `ContentProcess`, we need to perform a linear lookup within content processes during each callback, which makes the code O(n^2) where n is the number of content processes.
This patch rewrites this section of `RequestProcInfo` by splitting it as follows:
1. We use the same `GeckoChildProcessHost::GetAll` callback to examine non-ContentProcess, without any lookup.
2. We use the list of `ContentProcess` to examine ContentProcesses, without any lookup.
As a bonus, new code is not as deeply nested.
Differential Revision: https://phabricator.services.mozilla.com/D89364