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
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
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
WebIDL bindings do not need this method because console is a namespace.
All methods are static.
Depends on D6104
Differential Revision: https://phabricator.services.mozilla.com/D6105
--HG--
extra : moz-landing-system : lando
We'll need to support multiple worklets sharng a single execution thread for
AudioWorklet.
Depends on D6103
Differential Revision: https://phabricator.services.mozilla.com/D6104
--HG--
extra : moz-landing-system : lando
The comment is no longer accurate since
https://hg.mozilla.org/mozilla-central/rev/26b1ee21f365#l2.20
I've left the same behavior because checking that the caller has permission to
access the unwrapped constructor still seems sensible.
The JS::IsConstructor() check could be performed on |constructor| but I
guess it is a touch more efficient on constructorUnwrapped.
Differential Revision: https://phabricator.services.mozilla.com/D6564
--HG--
extra : moz-landing-system : lando
* Re-use about:preferences tab and just open sub-dialog for each test
* Add some instrumentation to provide some insight into any test timeouts.
* Re-enable for ccov
Differential Revision: https://phabricator.services.mozilla.com/D5485
--HG--
extra : moz-landing-system : lando
If a site had been granted persistent permissions, but hasn't accessed navigator.mediaDevices yet.
Then, we can't read the permission because MediaManager hasn't be created yet.
We should read these permissions without loading MediaManager.
In addition, I noticed that even user only requests 'screen' permission, we would also add the 'camera'
and 'microphone' permission in the nsIPermissionManager. That makes us no way to print the log to distinguish
what actually permission user granted.
Differential Revision: https://phabricator.services.mozilla.com/D6540
--HG--
extra : moz-landing-system : lando
To use this (Windows/Linux instructions), press Ctrl+L to give focus to the location bar. Shift+Tab to move focus backwards to the tab.
Ctrl+Left/Ctrl+Right to change which tab is focused
Ctrl+Space to add/remove a tab from the multiselection
Moving a tab has been changed from Ctrl+Left/Ctrl+Right to Ctrl+Shift+Left/Ctrl+Shift+Right, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D4670
--HG--
extra : moz-landing-system : lando
This patch uses a case-insensitive matcher to highlight the title of a history
entry that's been typed by the user. Previously the matching substring was
calculated manually as lowercase assuming that it's representation would have
the same number of characters as the original mixed case. In some locales
howerver this assumption is wrong leading to out-of-bound exceptions when
highlighting part of the title.
Differential Revision: https://phabricator.services.mozilla.com/D6661
--HG--
extra : moz-landing-system : lando
We're traversing primary frames, which are first continuations, so we can't
start from a continuation and expect to get to it. Add an assertion that would
catch further fishyness.
Differential Revision: https://phabricator.services.mozilla.com/D6672
--HG--
extra : moz-landing-system : lando
