This should be an easy solution. We can't stop the sign() or register()
runloop from calling the callback, so we need the callback to simply return
early when the U2FHIDTokenManager shuts down.
Bug #: 1400940
Differential Revision: https://phabricator.services.mozilla.com/D67
I also snuck in some last-minute assertions and minor fixes into this patch:
- don't stop reporting for a callee if we've seen it already (or rather, make the reachable set local to a root rather than global to all roots). This slows down runs with hundreds of hazards, but results in every problematic root being reported, for a more accurate count.
- annotate away some thread assertions
- special-case annotation for bug 1400435 since it's a whole family of hazards
--HG--
extra : rebase_source : ac7335d45e3e0772d34cb42cc6a3f628564fd3d1
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
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
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
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
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.
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.
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
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.
