- Implemented 1ms, 10ms, and 100ms VR tasks, dispatched from
VRManager
- Removed Android-specific code that compensated for
tasks that did not run when the...
...compositor was paused.
Differential Revision: https://phabricator.services.mozilla.com/D3378
--HG--
extra : moz-landing-system : lando
The suppressing of the error NS_ERROR_UNKNOWN_PROTOCOL will break the
web-platform-test 'windowclient-navigate.https.html' since navigating
to an invalid view-source url through the client API won't receive
any error due to the suppressing. So the test will time-out since it
waits for an error.
While navigating to an invalid view-source url with its inner url as
relative, this will pass the validity check we have right now and
do the navigation because of it takes account the baseURL while doing
the check. The invalid view-source url will be resolved into a valid
view-source url in the case. Fortunately, we won't encounter any issue
in the test in the past since the docShell will block this loading
because it's loading a view-source url inside an iframe and reports a
NS_ERROR_UNKNOWN_PROTOCOL error. But, we should faild with a
NS_ERROR_MALFORMED_URI error when doing the URL validity check.
For addressing this, this patch makes the client.navigate to not take
the baseURL into account if it is a view-source URL.
Differential Revision: https://phabricator.services.mozilla.com/D6587
--HG--
extra : moz-landing-system : lando
Return the document element as the activeElement when there is no body
element, the document is chrome privileged, and the document element
is a XUL element.
MozReview-Commit-ID: JFDLAqOmLTS
Differential Revision: https://phabricator.services.mozilla.com/D6448
--HG--
extra : moz-landing-system : lando
This changeset extends the async initialize functionality added in the prior
changeset by wrapping the Initialize resolver in a promise. This allows us to
use familiar promise machinery to handle async init of the CDM. We do this by
creating the promise and setting up handling when we receive the init message on
the ChromiumCDMChild, but resolving the promise in the `OnInitialized` callback
from the CDM to the ChromiumCDMChild.
We still only support CDM9 as of this changeset. As such, we now manually call
`OnInitialized` to make sure the ChromiumCDMParent is notified that the CDM has
initialized. When we implement the CDM10 interface, these manual calls will be
moved to the CDM9 compat layer, and Widevine CDM10+ can perform its own
callback.
This changeset adds a failure path to initialization, as the `OnInitialized`
interface we implement allows for failure. However, since we manually call into
this path for CDM9 we shouldn't get any such failures. Once CDM10 is fully
implemented its possible that the init callback could indicate failure, and the
handling here would be invoked.
Depends on D6061
Differential Revision: https://phabricator.services.mozilla.com/D6066
--HG--
extra : moz-landing-system : lando
Starting at the Widevine CDM10 interface, the CDM is expected to make a callback
to an `OnInititalized` function to signal initialization has taken place. Prior
to this, it was sufficient to call the init function on the CDM, with no waiting
for a callback.
This changeset puts in place the IPDL to support async init, as well as the
handling for the ChromiumCDMParent and ChromiumCDMProxy. The code is not fully
updated to handle CDM10, so CDM9 is the only compatible CDM. Because CDM9 does
not perform the init callback, we immediately call our IPDL to signal init has
taken place. This also accommodates the clearkey case, which uses the CDM9
interface.
Further changesets will put in place more elaborate handling to accommodate the
possible failure of init, as well as implementing the handling `OnInitialized`
function explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D6061
--HG--
extra : moz-landing-system : lando
Remove various calls to SetCapacity() that fall into various misuse categories:
1) Mistakenly believing that the caller should advice the string about zero
terminator.
2) Cases where a single append does the right computation on its own.
3) Calling SetCapacity() with a constant when the string is self-allocated
and could be an nsAuto[C]StringN and the string doesn't get passed on
in a way that could benefit from a heap-allocated buffer.
4) Calling SetCapacity() before assigning a shared buffer to the string.
5) Calling SetCapacity() before calling a function that will either calls
SetLength() anyway or calls Adopt().
MozReview-Commit-ID: IKjfl5gLmcD
Differential Revision: https://phabricator.services.mozilla.com/D4672
--HG--
extra : moz-landing-system : lando
This will be useful for AudioWorklet-specific storage and behavior.
PaintWorkletImpl is in layout/style, because it will be referenced
from CSS.cpp in the same directory.
Depends on D6108
Differential Revision: https://phabricator.services.mozilla.com/D6109
--HG--
extra : moz-landing-system : lando
This changeset extends the async initialize functionality added in the prior
changeset by wrapping the Initialize resolver in a promise. This allows us to
use familiar promise machinery to handle async init of the CDM. We do this by
creating the promise and setting up handling when we receive the init message on
the ChromiumCDMChild, but resolving the promise in the `OnInitialized` callback
from the CDM to the ChromiumCDMChild.
We still only support CDM9 as of this changeset. As such, we now manually call
`OnInitialized` to make sure the ChromiumCDMParent is notified that the CDM has
initialized. When we implement the CDM10 interface, these manual calls will be
moved to the CDM9 compat layer, and Widevine CDM10+ can perform its own
callback.
This changeset adds a failure path to initialization, as the `OnInitialized`
interface we implement allows for failure. However, since we manually call into
this path for CDM9 we shouldn't get any such failures. Once CDM10 is fully
implemented its possible that the init callback could indicate failure, and the
handling here would be invoked.
Depends on D6061
Differential Revision: https://phabricator.services.mozilla.com/D6066
--HG--
extra : moz-landing-system : lando
Starting at the Widevine CDM10 interface, the CDM is expected to make a callback
to an `OnInititalized` function to signal initialization has taken place. Prior
to this, it was sufficient to call the init function on the CDM, with no waiting
for a callback.
This changeset puts in place the IPDL to support async init, as well as the
handling for the ChromiumCDMParent and ChromiumCDMProxy. The code is not fully
updated to handle CDM10, so CDM9 is the only compatible CDM. Because CDM9 does
not perform the init callback, we immediately call our IPDL to signal init has
taken place. This also accommodates the clearkey case, which uses the CDM9
interface.
Further changesets will put in place more elaborate handling to accommodate the
possible failure of init, as well as implementing the handling `OnInitialized`
function explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D6061
--HG--
extra : moz-landing-system : lando
Create a new mochitest that suspends enumerateDevice(). This can happen when the current window navigates away. This is achieved by using an iframe to enumerate devices and clearing the iframe window before the promise is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D2709
--HG--
extra : moz-landing-system : lando
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga