This commit switches the identity popup to use "Content Blocking" as a top-level section
instead of Tracking Protection, which is now demoted to a category of Content Blocking.
To keep this change halfway reviewable, I avoided renaming variables, classNames, ids, etc.
that use the term trackingProtection if they were otherwise unaffected by this patch. There
will be other patches that can do this in the future
Differential Revision: https://phabricator.services.mozilla.com/D2775
--HG--
rename : browser/base/content/browser-trackingprotection.js => browser/base/content/browser-contentblocking.js
extra : rebase_source : 0dd57d6142c971617e9f47d32ce76a4a028d98eb
Multiple tabs in the same process could be viewing the same image. If it
is an image we are taking some time to download from the network, it may
not be displayed all at once. As a result, it could generate several
dirty rects for the newly decoded lines each time we paint. Since we
only apply the dirty rect to the active tab, and forget it afterwards,
then when one returns to the other tab(s), it may not reupload all of
the modified image data. Now we save the dirty rect and accumulate it
for the handles which weren't able to be updated immediately.
benchmar-report.js already has code like:
window.onload = function () {
document.body.removeChild(document.querySelector('main'));
startBenchmark();
}
So we avoid starting the test on load twice.
The throw when the style element was not there was saving us from reporting
twice, but the message interfered with the output that talos tries to parse.
At first sight, looks like this could also be a problem for speedometer, but
turns out it's not, since speedometer uses `<body onload="">`, and window.onload
overrides it.
That means that
https://hg.mozilla.org/mozilla-central/rev/162593bda5e167bea16b28637e85cc9d23f19c7c
is useless for Talos / Raptor, but it may be needed for PGO stuff, so I've kept
it for now.
Differential Revision: https://phabricator.services.mozilla.com/D3062
--HG--
extra : moz-landing-system : lando
Created specific notification channel dedicated to download progress notifications.
MozReview-Commit-ID: 88vsQiI2L2
***
--HG--
extra : rebase_source : 146563fd14a59299bc9bbba79fc9bdfd9e7ed37f
With asm.js atomics gone and wasm atomics opting in to standard
trap-based OOB handling, we should never fail to find a trap site. So
assert that we always find it, and remove code that is now dead.
--HG--
extra : rebase_source : 5ae030ab9ac92f48d84328c7ed5048ced299eb20
extra : source : 7dc12de9bf40160f8809bbe4fc16f4b54f6e5fa6
extra : histedit_source : 240aef6bd1195f13789d4da8d28a6698bc3dbbff
A large and mostly mechanical change: Prune the non-JS atomic APIs in
MacroAssembler.h and add many wasm-specific APIs instead.
The three non-JS APIs that remain in MacroAssembler.h could also be
removed but are used in multiple places to implement the JS APIs, and
it seemed fine to just leave them in. They are after all generally
useful.
Note, this patch changes MIPS code so that it compiles, but it does
not insert the necessary emitting of metadata, partly because the
mechanics of that for 64-bit ops on 32-bit systems depends on the
implementation of those 64-bit ops, and partly because I am happy to
let the MIPS maintainers do the work and check it. I have left behind
FIXME comments where changes are needed.
The one additional test case in jit-test is a result of closely
reading existing code and finding a bug that should have caused a
failure, but didn't, once the wasm/asm.js fallback for signal handling
was removed.
--HG--
extra : rebase_source : 4958997adb6050222bcde609dca6d00108c0a8f9
extra : histedit_source : b7fbcf868c60d7079d7827d98c7e7aad2d7d1f32
Similar to what we do for libstdc++ and glibc, we need to ensure that
we don't somehow end up with a dependency on a too new libgcc, which
can happen if it comes from gcc 7.0.
