An abnormal error is reported for empty data audio files in low-version browsers (webview)

problem background

There are a large number of static resource loading abnormal alarms in the monitoring, both ios and Android system versions (after a period of investigation, I found that QA students are testing in full, speechless)
QA test feedback, the report page stably reproduces the audio playback failure in the case of radio failure (there is indeed a problem, and the monitoring is effective)

Troubleshooting path

First, through the log data of the error event, it is found that there is no error message in the ErrorEvent, which is the first time I see it.
insert image description here
It is suspected that there is any special handling for audio error events. The errors of media replacement tags such as media and video found on the Internet belong to MediaError , and the information of the last error can be obtained through the ele.error.code of the element context.

This error code contains a total of four types:

name	value	illustrate
MEDIA_ERR_ABORTED	1	Resource request interrupted by user
MEDIA_ERR_NETWORK	2	Resource loading failed due to some network reasons
MEDIA_ERR_DECODE	3	resource decoding error
MEDIA_ERR_SRC_NOT_SUPPORTED	4	resource does not support

Confirm that the error message is 4 through the log, that is, the resource is not supported. It is suspected that there is a problem with the format.
insert image description here
After downloading the audio file and viewing it, the content also conforms to the wave standard, but the size is only 44Bytes, indicating that the file has no content.

So I went back to check whether the resource request was abnormal. Through the PerformanceResourceTiming API capability, I saw that the resource type was empty, and the resource type was not correctly identified.
insert image description here

Suspecting that the MIME format is non-standard, I checked the audio-related MIME MDN and found that audio/wave is standard, but if the encoding format is not 1, the support is limited.

Read the contents of the file again. It can be seen that the encoding format is 1, which is PCM (Pulse Code Modulation / Pulse Code Modulation), without signal compression.
insert image description here

I fell into a stalemate again. A curiosity drove me to check why there are two MIMEs, audio/wav and audio/wave. It turns out that these two are one thing. However, I still use the charles proxy to modify the response header and change content-type: audio/wave to audio/wav, but it doesn't work.
insert image description here

At this time, notice that in high-version devices, resource loading exceptions will be triggered, but audio error events will not be triggered. By comparing the resource data, it is found that the higher version system can identify the resource type.
insert image description here
Finally, the file is converted to mp3 format, the same problem. (It has nothing to do with the format type?)

In summary, the investigation link has come to an end.

specific cause

When the audio resource data is empty, some devices cannot decode the resource type, and directly trigger the MEDIA_ERR_SRC_NOT_SUPPORTED error.
The error bubbles up to the window, is captured by the outer layer and reported uniformly

Solution

Audio with a duration of 0 is considered illegal.

page not displayed
Error message distinction
Pocket default audio