The event listener callback wasn't bound to this, so the access to `activityErrorMap`
was failing.
This patch slightly modifies the event listener so we use a fat arrow function,
as well as adding the `once` option, since we were removing the event listener
the first time the callback was called.
Differential Revision: https://phabricator.services.mozilla.com/D138894
Previous fix was not enough to check whether orientation type is same or not.
If lock is resolved after `ScreenOrientation::MaybeChanged` is called,
`LockOrientationTask::Run` resolves promise unfortunately.
I should check previous orientation type instead.
Differential Revision: https://phabricator.services.mozilla.com/D137972
Even if platform implementation always returns error, `orientation.lock('any')`
is always successful. Because we don't wait for `LockDeviceOrientation`'s result
when current screen orientation is same as lock type. If
`LockDeviceOrientation` is failed, we should reject the promise.
Differential Revision: https://phabricator.services.mozilla.com/D137971
From https://w3c.github.io/screen-orientation/#apply-an-orientation-lock
> 7.2. Apply an orientation lock
>
> The steps to apply an orientation lock to a Document using orientation are as
> follows:
>
> 1. If the user agent does not support locking the screen orientation, return
> a promise rejected with a "NotSupportedError" DOMException and abort
> these steps.
So if orientation controller delegate isn't set, we should throw
`NotSupportedError`. But, actually, we throws `AbortError`, so this isn't
correct.
To return any DOM error from platform implementation of
`screen.orientation.lock`, I would like to change return value to
`GenericPromise`'s.
Differential Revision: https://phabricator.services.mozilla.com/D137970
Since no compat issues have been reported since we landed it in v98 beta,
it's time to remove the early-beta limitation.
The patch backs out 8ca70e015f3b863f9df6049d7b7d97123dafa640.
Differential Revision: https://phabricator.services.mozilla.com/D139972
PeerConnectionImpl needs its TransceiverImpls to be fully functional until it
is done closing, because Close performs a stats query.
Differential Revision: https://phabricator.services.mozilla.com/D139217
In some cases, PeerConnectionImpl's refcount will go to 0 without needing the
cycle collector to call unlink on it, which is what we rely on to call Close().
So, we make sure that refcount cannot go to 0 until Close is called (either
due to an unlink, or an explicit close from JS or PeerConnectionCtx).
Differential Revision: https://phabricator.services.mozilla.com/D139216
The ICE state "closed" is not (and never has been) used, and even if it were,
we would probably not want to decrement the PeerConnection count then anyway.
Also, remove an unused function.
Differential Revision: https://phabricator.services.mozilla.com/D139414
This avoids the situation where PeerConnectionCtx is holding onto bare pointers
to PeerConnectionImpl whose refcounts have gone to 0, which is a pretty big
footgun.
Differential Revision: https://phabricator.services.mozilla.com/D139214
StunAddrsHandler is not cycle collected, so it would either need to be made
cycle-collected, or it would need to use a weak ref instead. The latter is
much easier, since PeerConnectionImpl can clear that weak ref when appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D139212
There is now at most a single instance of PacketDumper per PeerConnectionImpl,
and it is owned by that PeerConnectionImpl. The flags/settings for packet dump
are kept in the PacketDumper itself instead of in PeerConnectionImpl, which
allows the early return optimization in Dump to work without a reference to the
PC.
Differential Revision: https://phabricator.services.mozilla.com/D139211
When the pc.close() calls in PeerConnection.jsm were removed, tests that did
not explicitly call pc.close() would result in situations where DataChannel
shutdown ran first, which resulted in DataChannels hanging around after
DataChannel ran its global shutdown code. So, we stop using xpcom-shutdown to
prompt DataChannel to shut down, and instead use ShutdownBlockingTicket to
ensure that shutdown does not proceed until DataChannel is cleaned up, which
naturally results from the PeerConnectionCtx shutdown code. However,
ShutdownBlockingTicket blocks xpcom-will-shutdown, not xpcom-shutdown, which
resulted in PeerConnectionCtx not getting an opportunity to run its shutdown
code, which then led to shutdown hangs. So, PeerConnectionCtx runs its shutdown
code at xpcom-will-shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D139210
