In addition to the returned MediaResult, a special number-of-tracks value
(not just 0) indicates an unrecoverable error.
For Rust-vs-Stagefright comparison purposes, an error is considered the same
as 0 (because Stagefright never returns errors, but Rust may, so complaining
about that would be too noisy, and useless to us.)
MozReview-Commit-ID: IwadWSOIWr4
--HG--
extra : rebase_source : 29f53ee6a02a0431adb0b615a122a4e7b480108c
The returned MediaResult is used as error or warning in MP4Demuxer::Init().
MozReview-Commit-ID: Bnv4xG8bCJ4
--HG--
extra : rebase_source : c1952ed61396834b0cd7da58c9b64481a5c46ab1
If 'media.playback.warnings-as-errors' is true, demuxing and decoding warnings
(i.e., non-fatal errors) will be treated as errors, causing playback to fail.
Currently set to false by default.
This could be later changed to catch and diagnose more issues.
MozReview-Commit-ID: BTaZ6TbIbNG
--HG--
extra : rebase_source : bacc24a46f588dd344e6d46178ae2d2c58882fcb
Similarly to the MediaFormatReader, TrackBuffersManager can forward warnings
from the demuxer initialization to the associated HTMLMediaElement.
Note that errors (sent to OnDemuxerInitFailed) are currently *not* forwarded
to the HTMLMediaElement by design. In the future, we may want to add this
feature so that mediasource errors can also be reported to webcompat.
MozReview-Commit-ID: GjluZbpmC9q
--HG--
extra : rebase_source : 57c02f86c56f054f209094d9697209300acc1288
The MediaFormatReader now takes the MediaResult from the Demuxer::Init promise
resolution, and if there are no other errors but the MediaResult is not NS_OK
it will forward that warning to the decoder owner (i.e., the associated
HTMLMediaElement).
MozReview-Commit-ID: 5rTmzqqPLI0
--HG--
extra : rebase_source : 5f81db185a01c012bf0418af2a42986db14a7e6f
If MP4Demuxer::Init detects some recoverable error (e.g., invalid tracks when
others may still be usable), it will eventually Resolve the promise with the
first warning.
Later on, errors/warnings from the MP4Metadata parser will also be handled, to
provide even better diagnostics.
MozReview-Commit-ID: E9Rly9dhXW3
--HG--
extra : rebase_source : cae214d0c80297bd61156dc1a305a186da0974fe
In case of successful initialization, there could still be some warning about
a recoverable error. To carry more information about this potential warning,
the resolve-value type of the promise is changed from nsresult to MediaResult.
Existing code doesn't need to be changed:
- In Resolve() calls, the stored MediaResult can implicitly be constructed from
an nsresult -- always NS_OK at the moment anyway.
- In following Then(), the promise's MediaResult can implicitly be converted to
an nsresult.
Future patches will modify some of the Resolve's and Then's, to forward warning
details to some Decoder Doctor object...
MozReview-Commit-ID: J0bXDFxXQHQ
--HG--
extra : rebase_source : cb10cdfa80e34783a459e5946b746b9f1920bd87
Mercurial uses the latest version of TLS that is both supported by
Python and the server.
In automation, the servers we care about should all support TLS 1.2.
The Python side is trickier. Modern versions of Python (typically 2.7.9+)
support TLS 1.1 and 1.2. Mercurial will default to allowing TLS 1.1+ -
explicitly disallowing TLS 1.0. However, legacy versions of Python
don't support TLS 1.1+, so Mercurial will allow TLS 1.0+ rather than
prevent connections at all.
TLS 1.0 is borderline secure these days. I think it is a bug for TLS
1.0 to be used anywhere in the Firefox release process. This simple
patch changes our default Mercurial config in TaskCluster to require
TLS 1.2+ for all https:// communications. For modern Python versions,
this effectively prevents potential downgrade attacks to TLS 1.1
(connections before should have negotiated the use of TLS 1.2).
I expect this change to break things. Finding and fixing automation
that isn't capable of speaking TLS 1.1+ should be encouraged.
MozReview-Commit-ID: 876YpL5vB3T
--HG--
extra : rebase_source : 69c33c195f736a98b67d771e7364b6db28900ff4
Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : 4d7f0880b2b4e8bd9424302bca16ef706e2fca25
This is a temporary measure until we have search complete and shipped (1353954).
MozReview-Commit-ID: KFeOefJ1RGM
--HG--
extra : rebase_source : 326a61f43e3e6f6d771b5bab713454945c9ee060
A couple other hidden="false" attributes were removed since they are unnecessary and shouldn't have been there. The changes to the downloadsGroup are because it is now nested inside of #applicationsContent.
MozReview-Commit-ID: IHZuKZUNYcR
--HG--
extra : rebase_source : f251849fd5a10bff8ad78554b96dc67c69a0ac78
This adds support for Visual Studio 2017.
Also need update cmake to 3.7.2.
r? @larsbergstrom
Can you please upload [this cmake](https://www.dropbox.com/s/3b2z36jj4gh4qpk/cmake-3.7.2.zip?dl=0) to s3 bucket?
Source-Repo: https://github.com/servo/servo
Source-Revision: 065f50014f321466c979120967da720e88ae2b29
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fc9a546379b96d67ef08979c4bc8258a3854ba59
Automation is now largely using Mercurial 4.1 with some lagging
components still on 3.9 and a very small sliver of random parts
still on 3.7.3. Let's update the mozharness tests to match what
automation is using.
FWIW, the Mercurial tests still pass on 3.9.
MozReview-Commit-ID: BgZVDcx29mf
--HG--
extra : rebase_source : edb8516491fe9ef616b1ad797be2fc02a89c2829
Tests based on this code fail in Mercurial 3.8+ due to `hg rebase`
changing its behavior for selecting default revisions. I was going
to update the code to work with 3.8+. However, I could find no actual
consumers of this method! Annotate says this was added back in
mozharness 0.4. However, I can't find a reason for it being added.
Nor can I find any consumers of this method in the mozharness repo
outside the tests. This smells like dead code to me.
MozReview-Commit-ID: 3Q6MTjQJT1p
--HG--
extra : rebase_source : 2c488b70136bc9856f6075297d7c32e3b69079ad
When symbols are not bound at load time, missing symbols can lead to
NULL derefs or jumps to 0x0 at runtime, crashing the process running
the corresponding JS code, which is rather undesirable. So, prevent
libraries that have missing symbols to load at all through ctypes.
--HG--
extra : rebase_source : e6a8162621dd9c5df410d9eec4224c7e79ea9819
The mercurial revision of sixgill listed in the manifest doesn't exist,
so I took what looks like corresponds to the last change to the tooltool
manifests, in order to avoid any other difference than GMP linkage.
This was built manually on a one-click-loaner.
--HG--
extra : rebase_source : 5ea830e48a6424a6ded9beab0628d0e562251c47
When panel behavior became asynchronous, |StarUI._doShowEditBookmarkPanel| needed to be changed to wait for the panel to finish opening before initializing it. Although the content of the panel can be changed successfully before the panel opens, the element focus at the end of initialization fails. This prevents the capturing of certain events, such as an Esc keypress (which should close the panel).
However, this introduced the problem where there is a short delay between when the bookmark panel opens and when the correct content is displayed in it. To fix this, the initialization function |gEditItemOverlay.initPanel| will now be called before the panel opens, but the element focus code will wait for the panel's popupshown event.
MozReview-Commit-ID: 6SrcCz963qW
--HG--
extra : rebase_source : c45f16913597b336dcae2717c0f902dbbe8025f2
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
MozReview-Commit-ID: JDJ3RtL4Lge
--HG--
extra : rebase_source : 7b49921bc653d57117f1c08212acc6c2db537984
extra : source : dd2d15dc577d9ec1ec16eb69d823c793dd1e9db0
This is from changeset 249a47720ddcf896a9f07600c429a1b4492b805e from
the version-control-tools repo. It contains a fix to restore
compatibility with Mercurial 3.7, which caused mozharness tests
to fail because that test pins Mercurial 3.7.3 in a requirements
file. This is a bug. But getting a modern robustcheckout deployed
is more important than upgrading that test.
<!-- Please describe your changes on the following line: -->
This is a PR of https://bugzilla.mozilla.org/show_bug.cgi?id=1354426
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because it's for stylo.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: e6a89899b0bf3e24e7f119e59a4e933bf967bb8d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 630353a1f0b16328ab985c98f3afc68c29516639
File copied verbatim from changeset e0d30b04dac6bcd36b57c711d9c5b1c280f63390
from the version-control-tools repository.
The updated extension now detects and retries after network failures
where it didn't before. This should cut down on the number of
intermittent failures.
MozReview-Commit-ID: 2bFLcGEARTJ
--HG--
extra : rebase_source : ac43b1925713ce33e1d0d835323efc02c30aed74
