Bug 1343442 - decode-error/warning tests - r?gijs MozReview-Commit-ID: A0HO6RrnpMC

Bug 1343442 - Handle decode-error/warning in browser-media.js - r?gijs Open webcompat.com in new tab, similar to what "Report Site Issue" button does. MozReview-Commit-ID: 1ESOY3upHgc

Bug 1343442 - Re-enable browser_decoderDoctor.js on Mac - r?gijs Thanks to the previous patch, these tests can now be run on Mac, though they don't do anything useful there just yet. MozReview-Commit-ID: 3HyN7ms1EPl

Bug 1343442 - Refactored DecDoc browser tests for extensibility - r?gijs Mostly moved things around to make future tests (using different parameter sets) easier to write. Also, all tests are now run on all platforms, but we're expecting nothing to happen in those cases that were previously skipped. It will be useful when we add tests that actually need to run on all platforms. MozReview-Commit-ID: AZTz9lr2eIJ

Bug 1343442 - Analyze eDecodeError/Warning issues - r?jya MozReview-Commit-ID: 97AhQz2Hgmi

Bug 1343442 - Provide appropriate params to console message - r?jya MozReview-Commit-ID: HiaY20UqksU

Bug 1343442 - Move NotificationAndReportStringId closer to first use - r?jya MozReview-Commit-ID: IBn5jsHTsKx

Bug 1343442 - Allow MediaDecodeError/Warning user notifications in Nightly - r?jya We want the new MediaDecodeError messages to be forwarded to the front-end in browser-media.js (even though they won't be handled just yet; an upcoming patch will add the handling code). This is limited to Nightly for now, like the "Report Site Issues" button, because we forward URLs to webcompat.com (at the user's request). And MediaDecodeWarning was not added, as it may cause too much annoyance, but it is available for testers to get more diagnostics information if needed. MozReview-Commit-ID: HPDpA1mg4HX

Bug 1343442 - MediaDecodeError/Warning user notification messages - r?jya These messages will be displayed in the Decoder Doctor drop-down notification bar. The message ids are also used internally to identify corresponding issues. MozReview-Commit-ID: MmKxCEoTok

Bug 1343442 - Decode-error/warning webidl notification types and data - r=smaug Decoder Doctor webidl additions: DecoderDoctorNotificationType.decode-error and decode-warning DecoderDoctorNotification.decodeIssue, docURL and resourceURL MozReview-Commit-ID: FK0YOCeuQMX

Bug 1341483 - MP4Metadata::GetTrackIndice() now also returns a success/error code - r?kinetik MozReview-Commit-ID: BIgvy5eKNJl

Bug 1341483 - MP4Metadata::Crypto() now also returns a success/error code - r?kinetik MozReview-Commit-ID: EywDv5JuDK6

Bug 1341483 - MP4Metadata::GetTrackInfo() now also returns a success/error code - r?kinetik MozReview-Commit-ID: KQ3fJzZkrGW

Bug 1341483 - MP4Metadata::GetNumberTracks() now also returns a success/error code - r?kinetik 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

Bug 1341483 - MP4Metadata::Metadata() now also returns a success/error code - r?kinetik The returned MediaResult is used as error or warning in MP4Demuxer::Init(). MozReview-Commit-ID: Bnv4xG8bCJ4

Bug 1343437 - 'media.playback.warnings-as-errors' pref - r?jya 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

Bug 1343437 - TBM::OnDemuxer{Init,Reset}Done forward non-NS_OK MediaResult to HTMLMediaElement::DecodeWarning - r?jya 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

Bug 1343437 - MFR::OnDemuxerInitDone forwards non-NS_OK MediaResult to HTMLMediaElement::DecodeWarning - r?jya 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

Bug 1343437 - MP4Demuxer::Init resolves with a MediaResult - r?jya 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

Bug 1343437 - MediaDataDemuxer::InitPromise resolve-value is now a MediaResult - r?jya 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