This allows us to run the poisoning code after resizing the nursery,
ensuring that the correct region of that chunk is poisoned, fixing the bug.
This also simplifies the logic around how much of the nursery to poison, we
always poison the valid region of the nursery regardless of how much was
used (removing an earlier optimisation).
Differential Revision: https://phabricator.services.mozilla.com/D36315
--HG--
extra : moz-landing-system : lando
With retained display lists, a content render root might get marked as not
needing a build, in which case the nsDisplayRenderRoot::CreateWRCommands
function does an early exit. In this case, we don't mark the associated
WebRenderUserData as used during the display list build, which causes it to
get deleted at the end of the transaction. The next transaction that
doesn't early-exit will re-create the WebRenderUserData with a new boundary
object. The compositor therefore thinks it's a brand new thing and, if
conditions are right, could end up destroying and re-creating much of the
APZC tree. That in turn can have effects like discarding paint-skipped
scrolling.
This patch ensures we always touch the WebRenderUserData during the display
list build, so we don't discard it. This problem may still affect nested
nsDisplayRenderRoot instances but I don't think we ever cases where those
occur.
Depends on D36386
Differential Revision: https://phabricator.services.mozilla.com/D36387
--HG--
extra : moz-landing-system : lando
Before this change, the accessibility icon was too close to the text beside it
on the RTL versions of Firefox.
Now a margin has been added to create sufficient space between the icon and
the text.
Differential Revision: https://phabricator.services.mozilla.com/D36014
--HG--
extra : moz-landing-system : lando
The test was relying on selectionchange events fired on an input text element.
This event is behind a pref, flip the pref to true during the test in order to make it
pass on all channels
Differential Revision: https://phabricator.services.mozilla.com/D36330
--HG--
extra : moz-landing-system : lando
With Fission enabled, remote types can have the form
webIsolated=<URI>. This is bad, because we store them in telemetry in
some places. This patch adds and uses a method that sanitizes remote
types.
Differential Revision: https://phabricator.services.mozilla.com/D36068
--HG--
extra : moz-landing-system : lando
Per spec, "border" is parsed as a non-negative integer, only mapped if nonzero
(though this is not observably different from mapping even if 0, except if user
or UA stylesheets style the border), and supported on img, object,
<input type="image">, but NOT embed, iframe, or marquee.
This matches the Chrome and Safari behavior, as far as I can tell. The
substantive change here is that we are removing mapping for the <embed border>
case.
Differential Revision: https://phabricator.services.mozilla.com/D36376
--HG--
extra : moz-landing-system : lando
Per spec, "hspace" and "vspace" are parsed as dimension attributes and are
supported on the following elements: embed, iframe, img, object,
<input type="image">, marquee. Except no one implements this for iframe.
https://github.com/whatwg/html/issues/4742 tracks the spec changing accordingly.
As far as hspace/vpace on <table> go, Safari supports them in both quirks and
standards mode, while Chrome doesn't support them in either mode. The HTML spec
doesn't have them supported at all, and neither does the quirks mode spec, so
I'm removing the quirks-only support we had to align with the specs and Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D36375
--HG--
extra : moz-landing-system : lando
The various margin attributes on <body> are "pixel length attributes" in the
spec, which should get parsed as non-negative integers. That said, Chrome and
Safari implement marginwidth, marginheight, marginleft, and margintop as
"dimension attributes" instead, and don't implement marginright and marginbottom
at all.
Differential Revision: https://phabricator.services.mozilla.com/D36372
--HG--
extra : moz-landing-system : lando
"charoff" isn't parsed specially in the spec, and nothing in our code uses the
parsed value.
Differential Revision: https://phabricator.services.mozilla.com/D36369
--HG--
extra : moz-landing-system : lando
In the new setup, if the value is an integer and fits in our restricted integer
range we store it directly; otherwise we just go ahead and store it as a double
in the misc container, since we have a double available there anyway.
Differential Revision: https://phabricator.services.mozilla.com/D36264
--HG--
extra : moz-landing-system : lando
* Remove WebGLBuffer::SetSlot
* Make most bindBuffer calls lazy.
* Replace nsTArray with std::vector in WebGLVertexArray.
Differential Revision: https://phabricator.services.mozilla.com/D36274
--HG--
extra : moz-landing-system : lando
This patch does the following:
1. Remove testing files from disk because they are no longer required.
2. Load completions from previous version of HashStore until an update
is applied.
3. Older version of HashStore(.sbstore) & PrefixSet(.vlpset) will be
removed during an update
Differential Revision: https://phabricator.services.mozilla.com/D36002
--HG--
extra : moz-landing-system : lando
Create test entries via update introduces performance overhead.
We can store them directly in LookupCache and do not save test entries
to disk.
Differential Revision: https://phabricator.services.mozilla.com/D34576
--HG--
extra : moz-landing-system : lando
For Safe Browsing V2, Data for lookup(LookupCache) and data for update(HashStore)
are now separated. |RegenActiveTables| doesn't need to check the chunk
number in HashStore.
Differential Revision: https://phabricator.services.mozilla.com/D34575
--HG--
extra : moz-landing-system : lando
Completions are now stored in .vlpset, we can remove it from .sbstore
Functions related to optimize reading completions from .sbstore can also
be removed because it is no longer HashStore's responsibility
Differential Revision: https://phabricator.services.mozilla.com/D34574
--HG--
extra : moz-landing-system : lando
1. VariableLengthPrefixSet supports getting/setting prefixes with
AddPrefixArray and AddCompletesArray
2. VariableLengthPrefixSet supports passing prefix as an integer in
Match API. This is because how V2 and V4 see prefixes as an integer
works differently.
Differential Revision: https://phabricator.services.mozilla.com/D34547
--HG--
extra : moz-landing-system : lando
The goal of the series of patches is to improve Safe Browsing performance by
skipping uncessary file IO.
The first two patches is to remove the dependency between LookupCache and HashStore, so HashStore is only
responsible for udpates.
Before this patch, LookupCacheV2 treats prefixes and completions
differently. It uses two data structures to maintain
prefixes:
1. mPrefixSet to store prefixes from .pset
2. mUpdateCompletions to store completions from .sbstore
After this patch
1. LookupCacheV2 & LookupCacheV4 both use variable-length
prefix set. mUpdateCompletions and mPrefixSet are removed and
mVLPrefixSet is used to store all prefixes data.
2. Move common function to base class.
Note that in this patch, conversion between 4/32 bytes prefixes and
mVLPrefixSet is not yet included, it will be handled in next patch.
This patch tries not to deal with any logic changes, only focus on refining
LookupCacheV2 & LookupCacheV4 class structure to use variable-length
prefixset for both classes.
Differential Revision: https://phabricator.services.mozilla.com/D34546
--HG--
extra : moz-landing-system : lando
This is a temporary fix for the tests in test_pref_rollout_workaround. The
tests are permafailing because they are now always running with MOZ_WEBRENDER=0
which breaks assumptions inside the test.