Fix potential issue(s) with audio/video playback in WebView. #4723
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We already had some old (and flawed) logic for handling the fetching of audio files, but only for OGG audio, since that was mostly the type of audio that is used in articles. There are now cases where MP3 audio files are used, which is causing similar issues as before.
Let's handle it this way:
If the WebView requests playback of an audio or video file, then we won't intercept it at all (which we were already doing for OGG files), and leave it for the WebView to handle on its own.
This also eliminates the need for our custom
AvailableInputStream
class, which was a poor attempt to fix the underlying issue, and actually wasn't even used: according to our logic, it was supposed to be used for OGG files, but then we're not intercepting OGG files. ¯\_(ツ)_/¯https://phabricator.wikimedia.org/T366437