After this patch, we may have the following files in SafeBrowsing
directory:
- (v2) .sbstore : Store V2 chunkdata, for update, MD5 integrity check
while load
- (v2) .pset : Store V2 prefixset, for lookup, load upon startup, no
integrity check
- (v4) .metadata : Store V4 state, for update, no integrity check
- (v4) .vlpset : Store V4 prefixset, for lookup, load upon startup,
CRC32 integrity check
- (v4) .pset : V4 prefix set before this patch, should be removed
The magic string is also added to ".vlpset" header so we can add
a telemetry to see if sanity check is good enough for prefix set
integrity check (The telemetry is not yet added). If yes, we can remove
the CRC32 in the future for even better performance.
Differential Revision: https://phabricator.services.mozilla.com/D21463
--HG--
extra : moz-landing-system : lando
SafeBrowsing prefix files LOAD/SAVE operations are handled in xxxPrefixSet.cpp.
It would be more clear if xxxPrefixSet.cpp only processes prefix data,
while LookupCacheV2/LookupCacheV4 which use prefix set process file.
This patch doesn't change any behavior, testcases need to update because
the LookupCache & xxxPrefixSet APIs are changed.
Differential Revision: https://phabricator.services.mozilla.com/D21462
--HG--
extra : moz-landing-system : lando
SHA256 is an expensive operation, we should avoid using them if
possible. SafeBrowsing prefix files are loaded during startup and
verify integrity with SHA256 which may affect the performance
especially on the low-end device.
This patch simply removes the SHA256 integrity check. CRC32 version
integrity check will be introduced in the other patch.
This patch also changes the behavior of recording
"Telemetry::URLCLASSIFIER_VLPS_LOAD_CORRUPT" a little bit.
It used to records only once per session(during startup, the first
time we load prefix set), now it records per update.
Differential Revision: https://phabricator.services.mozilla.com/D21461
--HG--
extra : moz-landing-system : lando
SafeBrowsing V4 protocol use SHA-256 as the checksum to check integrity
of update data and also the integrity of prefix files.
SafeBrowsing V2 HashStore use MD5 as the checksum to check integrity of
.sbstore
Since we are going to use CRC32 as the integrity check of V4 prefix files,
I think rename V4 "checksum" to SHA256 can improve readability.
Differential Revision: https://phabricator.services.mozilla.com/D21460
--HG--
extra : moz-landing-system : lando
I don't understand how the test ever worked. I think the idea was that each
operation would result in changes to the prefs, because those prefs are the
source of truth for the recent-files list. However, I don't understand why some
tests would not trigger multiple observer callbacks, which should have been a
huge mess.
The new code doesn't observe the prefs at all. Where possible, it waits for an
appropriate promise; in other places it uses `setTimeout()` to wait for the
next tick, relying on the Scratchpad implementation to be done reacting by
then.
Since the original code was event-driven, most tests were split across two
functions. Each test function had the bottom half of one test and the top half
of the next test. The new code uses async/await and can therefore at least
group related functionality into single cohesive test functions. But those test
functions aren't as independent as they look -- most of them still depend on
previous tests to set up the expected starting state.
Differential Revision: https://phabricator.services.mozilla.com/D20759
--HG--
extra : moz-landing-system : lando
Tests can use the promise to avoid racing on the text being available and the
UI ready for interaction.
Differential Revision: https://phabricator.services.mozilla.com/D20758
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
This maintains the important invariant that layers that carry scroll metadata
for the RCD-RSF are inside the async zoom container.
Differential Revision: https://phabricator.services.mozilla.com/D22049
--HG--
extra : moz-landing-system : lando
Switch to managing the buffer lifetime with a UniquePtr. This will make handling errors simpler in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D20579
--HG--
extra : moz-landing-system : lando
I don't understand how the test ever worked. I think the idea was that each
operation would result in changes to the prefs, because those prefs are the
source of truth for the recent-files list. However, I don't understand why some
tests would not trigger multiple observer callbacks, which should have been a
huge mess.
The new code doesn't observe the prefs at all. Where possible, it waits for an
appropriate promise; in other places it uses `setTimeout()` to wait for the
next tick, relying on the Scratchpad implementation to be done reacting by
then.
Since the original code was event-driven, most tests were split across two
functions. Each test function had the bottom half of one test and the top half
of the next test. The new code uses async/await and can therefore at least
group related functionality into single cohesive test functions. But those test
functions aren't as independent as they look -- most of them still depend on
previous tests to set up the expected starting state.
Differential Revision: https://phabricator.services.mozilla.com/D20759
--HG--
extra : moz-landing-system : lando
Tests can use the promise to avoid racing on the text being available and the
UI ready for interaction.
Differential Revision: https://phabricator.services.mozilla.com/D20758
--HG--
extra : moz-landing-system : lando
"browser.firstrun.*" seems to have been unused since the end of XUL-based
Fennec, whereas the code referencing the "browser.snippets.*" prefs was removed
in bug 1482836.
Differential Revision: https://phabricator.services.mozilla.com/D20862
--HG--
extra : moz-landing-system : lando
Now that fields are packed nicely, we can take advantage of the
contiguous layout of POD fields and read/write all the POD fields of a
given size in a single read/write call. For many structs, this should
have little or no effect, but for large structs such as LoadInfoArgs,
this reduces the number of function calls by ~50%.
Differential Revision: https://phabricator.services.mozilla.com/D22001
--HG--
extra : moz-landing-system : lando
We're about to start depending on how the fields are packed in a future
patch, so we should add some compile-time checking that our assertions
are correct.
Differential Revision: https://phabricator.services.mozilla.com/D22000
--HG--
extra : moz-landing-system : lando
We're going to read and write sentinels slightly differently for
bulk-writing adjacent fields, so let's factor out some reusable code for
doing so.
Differential Revision: https://phabricator.services.mozilla.com/D21999
--HG--
extra : moz-landing-system : lando
This patch changes the layout of IPDL-defined structs to order the POD
members by decreasing size, which ensures everything is packed well.
This optimization is only applied to the internal representation; the
external interface (e.g. constructors) is entirely unchaged.
Differential Revision: https://phabricator.services.mozilla.com/D21998
--HG--
extra : moz-landing-system : lando
This patch computes an ordering for the fields of an IPDL structure decl
such that they are packed well in memory. We'll take advantage of this
ordering in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D21997
--HG--
extra : moz-landing-system : lando
We can totally get there with a negative percentage basis, see comment 0 for an
example.
We could keep the warning like:
NS_WARNING_ASSERTION(clamping_mode == StyleAllowedNumericType::All ||
basis >= 0, "nscoord overflow?");
Which will catch cases where the style system would refuse to parse a negative
<length-percentage>, but we got a negative percent basis, which would be weird.
But that's a bit misleading since right now at least we rely on the caller to do
the appropriate clamping. I also think that NS_WARNING_ASSERTION is not very
useful, since we're not very likely to catch stuff with it. But anyhow, your
call.
Differential Revision: https://phabricator.services.mozilla.com/D22328
--HG--
extra : moz-landing-system : lando
Dorel Luca
hrdktg
Emilio Cobos Álvarez
Daniel Holbert
dlee
Jason Orendorff
berkay.barlas
Mike Hommey
Botond Ballo
Eric Rahm
Florian Quèze
Jason Laster
Jan Henning
Dave Townsend
Jan de Mooij
Nathan Froyd
Edouard Oger
Coroiu Cristina
Ricky Rosario
Dan Minor
Andrea Marchesini