nsStyleStruct has the field:

  nsBorderColors** mBorderColors;

It starts out nullptr, and when it is needed, it allocates an array of 4 nsBorderColors pointers. But the nsStyleStruct exclusively owns the array; nothing else can get at it. This change teaches the analysis that if 'this' is a safe nsStyleStruct*, then it should treat mBorderColors as if it were an inline length-4 array.

--HG--
extra : rebase_source : e9d4a550a728e403b3bb30e7dd61341c2680962d

--HG--
extra : rebase_source : eac8e39bab5a3979c1e18a5494c899af777a1958

Bug 1400442 - analyzeHeapWrites: getter_Copies preserves safety (similar to getter_AddRefs), r=bhackett

--HG--
extra : rebase_source : 4ae6297aa5725532bec513055dd451b8cbcf7bde

Bug 1400442 - analyzeHeapWrites: implement a cache for checking whether local variables are safe pointers, r=jonco

--HG--
extra : rebase_source : fce58842604238e6102f43057301fff27ee58d6f

Bug 1400442 - Refactor the --function debugging command line option (and alias it to -f) to analyzeHeapWrites.js, r=me

--HG--
extra : rebase_source : b8f81284ffe70712f2a245c495158c3584650ce4

This is for nicer output only, and does not affect the computation. A WorkListEntry contains a stack of CallSites, and the top of the stack represents the entry itself and so should share parameterNames. This changes fixes cases where some names were being registered in a different table than ended up being used by printouts.

--HG--
extra : rebase_source : e52bbc9ab3e4596d748ca2d729772a61cde1430a

--HG--
extra : rebase_source : c55d9900278cf6a31a16567e5ff658306c08e87c

--HG--
extra : rebase_source : 0ea91eb0373a1b0c848ce7e97f43a2006c190f29

Bug 1400442 - Targeted annotation for static local array of member pointers in LangGroupFontPrefs::Initialize, r=bhackett

The code is

    void
    LangGroupFontPrefs::Initialize(nsIAtom* aLangGroupAtom)
    {
        nsFont* fontTypes[] = {
            &mDefaultVariableFont,
            &mDefaultFixedFont,
            &mDefaultSerifFont,
            &mDefaultSansSerifFont,
            &mDefaultMonospaceFont,
            &mDefaultCursiveFont,
            &mDefaultFantasyFont
        };

        nsFont* font = fontTypes[3];
        font->size = 42;
    }

'this' is known to be a safe pointer (exclusively owned by the current thread), so a pointer to one of its members is also safe. But the analysis can't track safety across all that, so I have a special-case annotation here that says that fontTypes[3] returns a safe pointer if and only if 'this' is safe.

Note that all of those fields (eg mDefaultVariableFont) are nsFont structs, not pointers, so although you'd expect this to be one dereference away from a safe pointer's memory, it is not; assigning to font->size ends up being a write to some offset within the 'this' pointer, which is known to be safe here.

--HG--
extra : rebase_source : 60bf982911b8a66bc612cb5c7eeb04ec766ecf70

--HG--
extra : rebase_source : 206bba89c68e8dc37c135fed03490282eff61d76

--HG--
extra : rebase_source : 187dda47209195746d88a00733d9b806da2c4f14

--HG--
extra : rebase_source : ca41fae3c6f0507ed0be567ca5cd641e59475c8b

--HG--
extra : rebase_source : 950699da0c0d8c894542c71881cce3359a8c6697

--HG--
extra : rebase_source : 1cf32c7b383b2f2e8bbe44f8d09cb027b086ebbf

--HG--
extra : rebase_source : de700225cbfcfc4a3fad56327d9007eabff02859

Bug 1400466 - Cache the information loaded from src_comp.xdb into a structured clone buffer, r=jonco

Note that this requires some enhancements to the JS engine to support reading and writing structured clone data from/to files.

--HG--
extra : rebase_source : 444a2d407bd231efbba4b6b648eeb151f02177db

Bug 1400466 - Implement minimum necessary to allow saving and loading structured clone data, r=jonco

--HG--
extra : rebase_source : ea13ebcc1b3958c99cf04e7345da1aab5536b0ee

I wasn't sure what the right behavior for the U2F API is when `.sign()`
or `.register()` is called but there's an ongoing request that wasn't fulfilled
yet.

I think it makes sense to deny the request (as we currently do) when a request
of the same type is currently active. When however sign() -> register() or
vice-versa is called then we should cancel the previous request and start
the new one. From what I understand from reading the spec we definitely should
call the callback before starting the new request.

Bug #: 1401019

Differential Revision: https://phabricator.services.mozilla.com/D70

This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream.  This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting.  This patch just removes the footgun
by getting rid of the multiple inheritance.

Backed out changeset 3c9e25405f59 (bug 1401204) an request from baku for landing with wrong bug number. r=backout

This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream.  This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting.  This patch just removes the footgun
by getting rid of the multiple inheritance.

Bug 1400898 part 4.  Get rid of nsIDOMChromeWindow methods that are unused from C++, and mark the rest [noscript].  r=farre

MozReview-Commit-ID: GtYmfg6XiaQ

C++ code only reads this attribute.  Code that sets it comes via WebIDL bindings.

MozReview-Commit-ID: 2itFAxUVTBo

MozReview-Commit-ID: 4FuJSgha5y3

MozReview-Commit-ID: I31eceiJP55

The runloop seems like a good candidate for moving into its own crate.

I wasn't sure whether we want it under the Mozilla org on GitHub, so I pushed
it to ttaubert/rust-runloop for a start. Moving the repository to mozilla/*
is easy, and we'd just need to bump the crate version with the updated
repository, if you think we should.

Bug #: 1400559

Differential Revision: https://phabricator.services.mozilla.com/D62

--HG--
rename : dom/webauthn/u2f-hid-rs/src/runloop.rs => third_party/rust/runloop/src/lib.rs

MozReview-Commit-ID: BjU6A9pOpKE

--HG--
extra : amend_source : df945e1a1c60ed7973079b82ddeddadb79696ebd

Currently if SourceSurfaceVolatileData::Map fails due to being purged,
we expect that the surface will be discarded by the caller. This has not
consistently been the case, and as such, we should ensure we do not
forget if a buffer was previously purged when we reacquire it. Since we
do not at this time support repopulating an already allocated buffer
with new data, we cannot reset this state once it has been set.

Bug 1380649 - Part 1. Ensure SurfaceCache::CollectSizeOfSurfaces removes purged volatile buffer-backed surfaces. r=tnikkel

When we lookup a surface in the cache, we are careful to remove any
surfaces which were backed by volatile memory and got purged before we
could reacquire the buffer. We were not so careful in doing that when
generating memory reports. ISurfaceProvider::AddSizeOfExcludingThis will
cause us to acquire the buffer, and if it was purged, forget about its
purged status. Later when we performed a lookup, we would forget the
purged status, and assume we have the right data. This would appear as
completely transparent for BGRA surfaces, and completely black for BGRX
surfaces.

With this patch, we now properly remove purged surfaces instead of
including them in the report. This ensures that the cache state is
consistent. This also resolves memory reports of surfaces which reported
using no data -- they were purged when the report was generated.

Additionally, there was a bug in SurfaceCache::PruneImage where we did
not discard surfaces outside the module lock. Both PruneImage and
CollectSizeOfSurfaces now free any discarded surfaces outside the lock.

Bug 1396613 - Make proxy objects override handler's objectMoved method rather than using class hook r=sfink r=mccr8 r=peterv

Bug 1396613 - Update the object moved hook to allow it to be called when tenuring nursery objects r=sfink r=mccr8