Summary:
This patch aims to clean up the WebAuthnManager's state machine, especially
to make cancellation of transactions clearer. To fix bug 1403818, we'll have to
later introduce a unique id that is forwarded to the U2FTokenManager.
There are multiple stages of cancellation/cleanup after a transaction was
started. All of the places where we previously called Cancel() or
MaybeClearTransaction() are listed below:
[stage 1] ClearTransaction
This is the most basic stage, we only clean up what information we have about
the current transaction. This means that the request was completed successfully.
It is used at the end of FinishMakeCredential() and FinishGetAssertion().
[stage 2] RejectTransaction
The second stage will reject the transaction promise we returned to the caller.
Then it will call ClearTransaction, i.e. stage 1. It is used when one of the
two Finish*() functions aborts before completion, or when the parent process
sends a RequestAborted message.
[stage 2b] MaybeRejectTransaction
This is the same as stage 2, but will only run if there's an active transaction.
It is used by ~WebAuthnManager() to reject and clean up when we the manager
goes away.
[stage 3] CancelTransaction
The third stage sends a "Cancel" message to the parent process before rejecting
the transaction promise (stage 2) and cleaning up (stage 1). It's used by
HandleEvent(), i.e. the document becomes inactive.
[stage 3b] MaybeCancelTransaction
This is the same as stage 3, but will only run if there's an active transaction.
it is used at the top of MakeCredential() and GetAssertion() so that any
active transaction is cancelled before we handle a new request.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409434
Differential Revision: https://phabricator.services.mozilla.com/D132
This change requires introducing nsID::Clone(). Because it's infallible, the
patch also removes some redundant failure-handling code. (nsMemory::Clone() is
also infallible, so this code was redundant even before this change.)
--HG--
extra : rebase_source : ef22757d3fa814320490bf7e19e822b8f0c4bdc3
In come cases, we can fail the IPC message, but in one we can't really do anything.
MozReview-Commit-ID: 4vdKIRUOJNN
--HG--
extra : rebase_source : b32559b4d88017612c35346f83cb11cb5b522252
Summary:
We can simplify and reduce the {WebAuthn,U2F}Manager code by removing these
methods and sending messages directly from closures.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409357
Differential Revision: https://phabricator.services.mozilla.com/D131
mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
Upgrade the test names from 3.0/3_0 to 2.1/2_1, consistent with the changes
made in part 1.
--HG--
rename : dom/quota/test/unit/test_version3_0upgrade.js => dom/quota/test/unit/test_version2_1upgrade.js
rename : dom/quota/test/unit/version3_0upgrade_profile.zip => dom/quota/test/unit/version2_1upgrade_profile.zip
extra : rebase_source : f0b33f52d9247ed4b14a2debc22551f98b211741
extra : source : efc62fb7fa68968335c605cf54f1d94631bc3b33
Alter 57 and 58 DOM Cache API to use an on-disk schema version of 25 again,
as was used prior to the landing of bug 1290481 that bumped the disk schema
version to 26. Patched versions will recognize this internally as schema 27
based on the presence of the column introduced by the 26 upgrade.
--HG--
extra : rebase_source : 03d6e361ef71de03e99bd27bc27a95ed65ecb846
extra : source : 523debab77daab9f69ca9ea19412c655e6d1e02f
To improve the Firefox 57 to 56 downgrade scenario, have 57 and 58
re-number the version 3.0 schema introduced by bug 1290481 to
version 2.1. Firefox 56's Quota Manager will recognize the minor
schema version and accept the schema from the future.
--HG--
extra : rebase_source : c2458e380966e4f1ec60a6df5f01135231f308fe
extra : source : e895c35e9b4e9dbc6849d40d644af97c028fffcf
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
CreateDecoder is the only caller of InstantiateDecoder, and all CreateDecoder
does is call InstantiateDecoder.
MozReview-Commit-ID: KwwL2el8L4x
--HG--
extra : rebase_source : bff225558fd2de535c2cb010eb35b95c6d9469e5
We can use Selection directly instead of nsISelection. It means that we don't need QI for nsISelectionPrivate. So IMEContentObserver should hold Selection instead if nsISelection.
MozReview-Commit-ID: 4jp9wWHRHRd
--HG--
extra : rebase_source : 9f4792cf75555b5aafdacfd8f137e68d9da86e04
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
Per the CSP specification, content injected by extensions is meant to be
exempt from page CSP. This patch takes care of the most common case of content
injected by extension content scripts, which always have expanded principals
which inherit from the page principal.
In a follow-up, we'll probably need to extend the exemption to stylesheet
content loaded by extension codebase principals.
MozReview-Commit-ID: GlY887QAb5V
--HG--
extra : rebase_source : 1371b4e4e7f330b7f7721d4aa169fcb52a7622d0
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
This avoids the need for numerous 8-to-16-bit and 16-to-8-bit string
conversions.
The patch also introduces a higher-order macro, FOR_EACH_CSP_KEYWORD, which
defines all the stuff about the keywords in a single place and makes the code
nicer.
--HG--
extra : rebase_source : b0f655546aa397749bb18dc7d6d27fbc12fe8fca
This is similar to Services.tm.idleDispatchToMainThread, but provides an
IdleDeadline argument to its callbacks, the same way that
Window.requestIdleCallback does.
The IdleDeadline argument was necessary for my first attempt at this bug. It's
not necessary for the current version, but I suspect it will be useful in
other areas, and it also avoids some XPConnect overhead, so it's probably
worth keeping.
MozReview-Commit-ID: FtrbNkE7Vz5
--HG--
extra : rebase_source : d28973641e914c8d180f66125669aabc29ab857f
Since the presence of an entry with a null selector is different for Gecko and
Servo, this seemed easier, and mimics nsLayoutStyleSheetCache.
Also, this is going away soon anyway as soon as I get to implement the rest of
the methods for stylo.
MozReview-Commit-ID: DtHJbw8C0GX
--HG--
extra : rebase_source : dd450a6972054971eba8bba5bb022b74d07c2a0b
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
ChildPrivileges is a leftover from the B2G process model; it's now
mostly unused, except for the Windows sandbox using it to carry whether
a content process has file:/// access.
In general, when sandboxing needs to interact with process launch, the
inputs are some subset of: the GeckoProcessType, the subtype if content,
various prefs and even GPU configuration; and the resulting launch
adjustments are platform-specific. And on some platforms (e.g., OS X)
it's all done after launch. So a simple enum used cross-platform isn't
a good fit.
MozReview-Commit-ID: K31OHOpJzla
--HG--
extra : rebase_source : 3928b44eb86cd076bcac7897536590555237b76b
Reorder WebAuthentication.webidl to match the ordering of the IDL index in
the Web Authentication spec. No normative changes.
MozReview-Commit-ID: 7qPE60Qh7Ly
--HG--
extra : rebase_source : 18f18a85c013528bf9b2ec84165f7a32a134c3d7
This covers these renames:
* In CollectedClientData, hashAlg => hashAlgorithm
* In CollectedClientData, tokenBinding => tokenBindingId
* In MakePublicKeyCredentialOptions, parameters => pubKeyCredParams
* In MakePublicKeyCredentialOptions, excludeList => excludeCredentials
* In PublicKeyCredentialRequestOptions, allowList => allowCredentials
* Transport (WebAuthnTransport in Gecko) => AuthenticatorTransport
MozReview-Commit-ID: 3FdRnkosy83
--HG--
extra : rebase_source : 22f124c781b03837ad0cd4be4edf34527e3b9d38
This covers these renames:
* In PublicKeyCredentialParameters, algorithm => alg
* MakeCredentialOptions => MakePublicKeyCredentialOptions
* PublicKeyCredentialEntity => PublicKeyCredentialRpEntity
* Attachment => AuthenticatorAttachment
It sets a default excludeList and allowList for the make / get options.
It adds the method isPlatformAuthenticatorAvailable which is incomplete and
not callable, to be completed in Bug 1406468.
Adds type PublicKeyCredentialRpEntity.
Adds "userId" to AuthenticatorAssertionResponse.
Adds "id" as a buffer source to PublicKeyCredentialUserEntity and as a
DOMString to PublicKeyCredentialRpEntity, refactoring out the "id" field
from the parent PublicKeyCredentialEntity.
It also adds a simple enforcement per spec 4.4.3 "User Account Parameters for
Credential Generation" that the new user ID buffer, if set, be no more than
64 bytes long. I mostly added it here so I could adjust the tests all at once
in this commit.
MozReview-Commit-ID: IHUdGVoWocq
--HG--
extra : rebase_source : bc1793f74700b2785d2bf2099c0dba068f717a59
WebAuthn has added a flag UV to indicate the user was biometrically verified. We
have to make sure not to set that flag for U2F. Turns out we already do that,
but let's add the constant and such.
Ref: https://w3c.github.io/webauthn/#authenticator-data
MozReview-Commit-ID: 6Qtjdkverls
--HG--
extra : rebase_source : 660348596b917d8f461b19298e01dbe19410b63f
There are currently some corner cases where channels that are eventually
loaded into documents (mainly <img src="data:image/svg+xml,") can inherit
expanded principals from a caller. Since documents aren't allowed to have
expanded principals, this causes crashes.
This patch is a short term workaround for the issue, until we have a longer
term solution that prevents the channels from inheriting the expanded
principals to begin with.
MozReview-Commit-ID: JwqqtVynLjj
--HG--
extra : rebase_source : 23199517414428924e9c78629ac794b54bd23c52
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : 44ea3d0eb292e5c285d0aa4e10eefa41f20beed7
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 0334b71534cfaccaf1d8985d827fe4e5d5bf0e9f
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : b1dc3193d839ef3776195901339fae24f328207b
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
I don't know whether or not another zero initial AudioChunk member value
makes initialization more efficient, but zero for silence is more intuitive
for humans.
MozReview-Commit-ID: JEYv65btMul
--HG--
extra : rebase_source : 3089362ce4773da91c7139a3127e1491cbcf1dc5
This avoids any risk of undefined behavior when evaluating uninitialized
members, during copies for example, and makes it safe to test mBufferFormat
when null.
MozReview-Commit-ID: IMAyZ1CSHbk
--HG--
extra : rebase_source : b02431634732cf63d6fe9ede5eb1400a2baa6308
The imgLoader code consistently uses the term 'loadingPrincipal' for the
principal that is called the triggeringPrincipal everywhere else it's used.
This is confusing, and since we need to make changes to how those values are
determined, it should be fixed beforehand.
MozReview-Commit-ID: 8CTHwayzcaD
--HG--
extra : rebase_source : d4405b0ecfe1c8dfb9bfdf61fe6ed6cfb180ba83
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
Once we call DoneAddingChildren, random code of various sorts will run, which
can flush our notification state. If that happens before we've notified on our
kids, but after we've popped the element we're closing off the element stack,
we will fail to ever notify on the kids.
MozReview-Commit-ID: Ei7v5OobX8R
Tim Taubert
Bob Owen
Sebastian Hengst
Phil Ringnalda
Andrea Marchesini
btian
Nicholas Nethercote
Tom Ritter
Dragana Damjanovic
Bob Clary
Robert Longson
Ben Kelly
Randell Jesup
Boris Zbarsky
Alastor Wu
Andrew Sutherland
Dan Minor
Valentin Gosu
Thomas Nguyen
Jeff Gilbert
Brendan Dahl
Emilio Cobos Álvarez
Kris Maglione
JW Wang
Ethan Lin
Chris Pearce
Cameron McCormack
bechen@mozilla.com
Kearwood Gilbert
Makoto Kato
Joel Maher
David Major
Dan Banner
Kyle Machulis
Steve Fink
Edgar Chen
sotaro
Xidorn Quan
Christoph Diehl
Ryan VanderMeulen
Shawn Huang
Jason Orendorff
Catalin Badea
Gerald Squelart
Mike Hommey
Jed Davis
J.C. Jones
Luca Greco
Luke Wagner
Shane Caraveo
evilpies@gmail.com
Jean-Yves Avenard
James Cheng
Hiroyuki Ikezoe
Karl Tomlinson
Stone Shih
Tobias Schneider
Ehsan Akhgari