The promisePanelEvent function was unreliable because it did not raise an error if the provided panel did not exist, which caused one of the callers to ignore a missing panel silently. All the callers have now been updated based on whether they expect the panel to exist or not.
MozReview-Commit-ID: AGT4rHls4OB
--HG--
extra : source : 0857964174624b1cf3d4ea3ffa94ba21b090788a
extra : intermediate-source : 29972a52d5c4829eb7fd662792836c934b1d11d8
Summary:
Always replace attestation statements with a "none" attestation.
Bug 1430150 will introduce a prompt that asks the user for permission whenever
the RP requests "direct" attestation. Only if the user opts in we will forward
the attestation statement with the token's certificate and signature.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1416056
Differential Revision: https://phabricator.services.mozilla.com/D567
If there is an active provider which has yet to produce a frame, any
calls to SurfaceCache::Lookup will return MatchType::PENDING. If
RasterImage::Lookup gets the above result while given FLAG_SYNC_DECODE,
it will attempt to start a new decoder. It is entirely possible that
when we try to insert the new provider into the SurfaceCache, it cannot
because the original provider finally did produce something. In that
case we should abandon attempting to redecode and retry our lookup.
These asserts are somewhat faulty given the
image.downscale-during-decode.enabled preference is a live preference
and thus can change at any time. Given the decision to downscale is made
on the main thread, and it is asserted on a decoder thread, this will
always be inherently racy. Most of the time this isn't a problem, but
with our automated tests, we frequently flip this preference, and the
assertion may fail unnecessarily with an unrelated image. The reftests
themselves verify downscaling did or did not occur based upon comparison
to the reference, and don't require the assert for verification.
This will allow us to hide the input for the browser console.
MozReview-Commit-ID: AOltH7HakQE
--HG--
extra : rebase_source : 6f5f278ea69af479c8e1eda87f939ac30a8d6ae7
This patch only fixes warning, not changing actual behavior of editor.
HTMLEditRules::ReturnInParagraph() splits paragraph *around* given point.
Therefore, from point of view of caller, offset of setting point may be
invalid after HTMLEditRules::ReturnInParagraph() handled the edit action.
In this case, invalidating stored child of the point may cause warning
since offset may be larger than length of its container.
So, if HTMLEditRules::ReturnInParagraph() handles the edit action,
the caller, HTMLEditRules::WillInsertBreak(), should cancel invalidating
the stored child for avoiding unnecessary warning.
MozReview-Commit-ID: DKJlr0Awwlo
--HG--
extra : rebase_source : 8fbefff3b46e55daf8db6342f00de904315d7fcc
A pipe is no longer used for the input stream, instead we use a string stream
which in most cases will be able to share the string data buffer rather than
copying it.
--HG--
extra : rebase_source : 75c9954154acd78b48ccfef61ad9cd9403218f96