Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
Please review the changes to Errors.msg very carefully. I caught a number of
mistakes there in self-review (e.g. not renumbering replacement markers
correctly when I added {0} to the beginnings of strings), and my confidence
that I caught them all is only middling.
A few lines (MSG_USELESS_SETTIMEOUT, MSG_TYPEDARRAY_IS_DETACHED,
MSG_NOT_SUBMIT_BUTTON) were removed from Errors.msg either because they were
already unused or because they either were single-user constant strings or
became such in the new setup and we could just use the string version of
ThrowTypeError.
Differential Revision: https://phabricator.services.mozilla.com/D61523
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
In most of the cases, the value to be stored is the same as the existing value, which does not require an update to the database. Setting something in the database requires disk access. By using this we avoid accessing the disk in the majority of the cases.
Differential Revision: https://phabricator.services.mozilla.com/D45504
--HG--
extra : moz-landing-system : lando
The problem reproduces when the system is loaded and the decoder is dropping most of the frames. When there are two benchmark calculations close to each other, the measured parsed frames of the first calculation can be buffered in the decoder and reported as dropped frames on the second calculation. Then on the second calculation, the number of dropped frames can be greater than the parsed frame which will hit the assert. The number of total frames is a better measure since it counts the frames that appeared in the in VideoSink plus the total dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D44478
--HG--
extra : moz-landing-system : lando
Introduce a static method to call the CheckVersion method of the IPDL protocol from the content process. Every time a video decoder is initialized, the method is called to verify the version of the stored benchmark entries.
Differential Revision: https://phabricator.services.mozilla.com/D41003
--HG--
extra : moz-landing-system : lando
The new protocol method transfers the database name and the version number from the content to the parent process. Then the parent process retrieves the stored version number from the database and compares it to the provided version number. If they are the same it stops there, otherwise it erases all the entries from the database and stores the new version number.
Differential Revision: https://phabricator.services.mozilla.com/D41002
--HG--
extra : moz-landing-system : lando
Add a new method in the key-value wrapper (KeyValueStorage) to clear all the entries of a database.
Differential Revision: https://phabricator.services.mozilla.com/D41001
--HG--
extra : moz-landing-system : lando
Create an event in MediaFormatReader the will signal to the HTMLMediaElement to initiate a new storing according to the latest VideoInfo. Also when the application is shutting down, trigger a new storing early enough, before all the events are disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D38316
--HG--
extra : moz-landing-system : lando
Make use of the new DecoderBenchmark class in MediaCapabilities instead of the old Benchmark mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D38315
--HG--
extra : moz-landing-system : lando
Create a class that gets the video properties and the frame statistics, calculates the score in percentage for that video playback, creates a key string according to video properties and trigger the storage of the score.
The video properties used are the resolution, the frame rate and the bitdepth.
For the key, a range of levels has been created for each property and the video is categorised on the closest levels. The key consists of the various levels like: "ResolutionLevel5-FrameRateLevel1-8bit".
Finaly, it uses the IPDL protocol to store the pair of the score and the key.
Differential Revision: https://phabricator.services.mozilla.com/D38314
--HG--
extra : moz-landing-system : lando
The database is accessible from the parent process due to to the sandbox thus it is required an IPDL protocol that will transfer the queries and the results
Differential Revision: https://phabricator.services.mozilla.com/D38313
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This partially backs out bug 1471165 now that we don't enforce a default value
for dictionary-typed members of dictionaries.
Differential Revision: https://phabricator.services.mozilla.com/D6876
--HG--
rename : testing/web-platform/meta/media-capabilities/decodingInfo.html.ini => testing/web-platform/meta/media-capabilities/encodingInfo.html.ini
rename : testing/web-platform/tests/media-capabilities/decodingInfo.html => testing/web-platform/tests/media-capabilities/encodingInfo.html
extra : moz-landing-system : lando
This ensures on platform that requires it, that only a single decoder at a time are used, in effect serialising all the MediaCapabilities.decodingInfo requests.
Differential Revision: https://phabricator.services.mozilla.com/D3679
In bug 1404042, we determined that video playback of software based surface was very slow and power hungry when using the intel GPU, but was working okay when using the dGPU (either AMD or nVidia)
So always return false in IsVP9DecodeFast when the current GPU is an Intel, as well as return a benchmark score of 0
Force a new run of the benchmarking by bumping the version number.
Differential Revision: https://phabricator.services.mozilla.com/D2075
--HG--
extra : moz-landing-system : lando
In bug 1404042, we determined that video playback of software based surface was very slow and power hungry when using the intel GPU, but was working okay when using the dGPU (either AMD or nVidia)
So always return false in IsVP9DecodeFast when the current GPU is an Intel, as well as return a benchmark score of 0
Force a new run of the benchmarking by bumping the version number.
Differential Revision: https://phabricator.services.mozilla.com/D2075
--HG--
extra : moz-landing-system : lando
Summary:
Additionally, consider all videos <= 480p to be smooth and power efficient as:
1- Hardware decoding it typically not used for those
2- We can't do any better
3- Any machines should be able to do 480p
Depends on D1794
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1796
Summary:
If the benchmark task hasn't run yet, we will assume smoothness for now.
Depends on D1771
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1772
Summary:
The Apple VT decoder requires SPS+PPS at construction time. If not provided, in earlier macOS it used to give an error. In the current 10.13 it appears to work, however the decoder always report to be software only.
To properly determine the decoder capabilities, we construct a SPS NAL from the codec mimetype provided.
Details on the structure of the mimetype can be found in https://tools.ietf.org/html/rfc6381#section-3.3 and is a 1:1 match with the data found in the SPS.
Depends on D1718
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1719
Summary:
By default, when creating a H264 decoder it is wrapped into a H264Converter which will only create the actual decoder once a valid SPS/PPS has been seen.
As creating valid SPS/PPS NALs isn't trivial, when all we care about are capabilities of such decoder, we do not wrap the decoder so that it will be immediately created.
We can then test its capabilities.
We only enable this on windows, as on mac we need to generate a SPS/PPS, otherwise the mac decoder always report that HW decoding is not enabled.
Depends on D1632
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1633
Summary:
To properly determine if a decoder is hardware accelerated, we must pass information about the compositor to the decoder.
Depends on D1631
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1632
Summary:
We now provides more detailed information for audio (check sampling rate and channels if provided).
And check for the power efficient attribute. We directly correlate this information with the decoder being hardware accelerated or not. All audio codecs are deemed to be power efficient.
Depends on D1626
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1627
Summary:
The information returned is identical to
1- canPlayType() for file
2- MediaSource.isTypeSupported for media-source
3- MediaRecorder.isTypeRecorder() for recordings.
Depends on D1616
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1617
Boris Zbarsky
Emilio Cobos Álvarez
Sylvestre Ledru
Alex Chronopoulos
Cosmin Sabou
Nicholas Nethercote
Jean-Yves Avenard
Dorel Luca
Coroiu Cristina