The new error is thrown if, for example, you try to create a ReadableStream via
the C++ API while streams are disabled.
Depends on D6553
Differential Revision: https://phabricator.services.mozilla.com/D6554
--HG--
extra : moz-landing-system : lando
Simply replace the nsCString with nsDependentCSubstring to avoid copying the data. In this way, we can also avoid the potential OOM crash.
Differential Revision: https://phabricator.services.mozilla.com/D6685
--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
Gtk+ sets .left/.right classes to GtkBox element at GtkHeaderBar according to button placement (left/right).
We don't support that now so set .left at least to be compatible with themes - BlueMenta for instance.
Differential Revision: https://phabricator.services.mozilla.com/D6657
--HG--
extra : moz-landing-system : lando
This test case will try to navigate an iframe to an unknown protocol and
check whether no errors been reported.
Differential Revision: https://phabricator.services.mozilla.com/D3493
--HG--
extra : moz-landing-system : lando
This patch makes the docshell not to report an error if it is a unknown
protocol error. However, we will still display the error page in this
case.
Differential Revision: https://phabricator.services.mozilla.com/D3492
--HG--
extra : moz-landing-system : lando
When reworking the script each entry holding a function name was replaced by a
dictionary holding both the function name and its size. This significantly
increased memory consumption as using a full-fledged dictionary for only two
fields is very space inefficient. This patch uses a named tuple instead of a
dictionary for every entry, reducing memory consumption by almost four times.
Differential Revision: https://phabricator.services.mozilla.com/D6603
--HG--
extra : moz-landing-system : lando
The first line which this patch is fixing was clobbering the object
that the tests were setting up, so all these tests were testing was
the blocking callback of the default runTest() path before this
patch.
Depends on D6747
Differential Revision: https://phabricator.services.mozilla.com/D6748
--HG--
extra : moz-landing-system : lando
There are a number of changes involved here which I'll try to summarize below:
1. Provide API calls to start & stop the tracelogger. These will enable and disable a set of events to trace.
2. Provide API calls to reset the tracelogger. This will empty the data structures used by the trace logger so that a new tracing session can occur without previous data corrupting it.
3. Provide API calls to write out the trace logger data in JSON. This will write out an array of strings which acts as the trace logger event dictionary, and an array of events with timestamps.
4. Implement a new way of storing the event strings. Previously, all strings were saved in the format "script:line:column". However, this led to a lot of duplication because many events would use the same script at different locations. Instead, we now save only the script string into a vector, and then hash it and save that into a table for reuse. The line and column will be saved as part of the text id payloads. Overall, this saves us about 100-150 MB of data for about a 10 second trace.
5. Add some necessary locks for when the gecko profiler calls some of the API routines from another thread.
Differential Revision: https://phabricator.services.mozilla.com/D5219
--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
