1834206 - [Devtools] Unable to Receive 206 Response or Filter by Media Type, but Content Remains Playable.

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[limkokhole]

Attachment: 1684666462_2023-05-21_oVpWb5HHde.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0

Steps to reproduce:

Visit: https://www.sohu.com/a/654891226_114830
Open the inspector -> network tab -> clear all -> Press Ctrl+F5 to refresh the webpage -> play the video.

Actual results:

Filtering by "Media" type resulted in a blank output. However, filtering by "All" and typing "https://video" displayed 2(or 1) entries with an unknown remote IP.

The video was playable, and I was able to manually download it by copying the entry as curl and removing the Range header.

Using my personal extension, diffhttp (https://addons.mozilla.org/en-US/firefox/addon/diff-http/), I could see a response code of 206, and the content-type "video/mp4" in the response header.

Expected results:

The HTTP status code 206 should have been displayed and should also have been filterable by media.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[limkokhole]

It should go to Devtools component.

Note that sometimes the entry with a 206 status code appears after manipulating the filtering/sorting options for a while, or after clicking on the duration bar.

Comment 3

[Julian Descottes [:jdescottes]]

Doing a quick check it seems that ESR does not show the error request, and if you filter on "media" the video request is still displayed. Might be worth having a regression window.

Comment 4

[limkokhole]

I tested the issue again. Here are the steps:

Visit: https://www.sohu.com/a/654891226_114830
Open the inspector and navigate to the network tab.
Clear all previous data and tick 'media'.
Press Ctrl+F5 to refresh the webpage.
Allow the video to auto-play. Do not interact with the page.

Note: The network request appears randomly, only after a delay of approximately 40 seconds to 1 minute."

Comment 5

[Julian Descottes [:jdescottes]]

(In reply to limkokhole from comment #4)

I tested the issue again. Here are the steps:

Just to clarify, we also reproduced the issue on Nightly (just updating the status from UNCONFIRMED to NEW). I was only mentioning that the ESR version of Firefox (which is version 102) didn't seem to have the issue, so it might be a regression between 102 and 114.

Comment 6

[Ciprian Georgiu, Desktop QA]

Interestingly, I'm able to reproduce the issue on 102.12.0esr as well with Win 11 x64. The requests are not displayed at all when filtering by "Media" type, the panel remains blank.

Hi limkokhole! Are you still seeing this issue with latest Nightly 116.0a1, can you please take a look?

Comment 7

[limkokhole]

(In reply to Ciprian Georgiu, Desktop QA from comment #6)

Interestingly, I'm able to reproduce the issue on 102.12.0esr as well with Win 11 x64. The requests are not displayed at all when filtering by "Media" type, the panel remains blank.

Hi limkokhole! Are you still seeing this issue with latest Nightly 116.0a1, can you please take a look?

My version is Firefox Developer Edition 115.0b (up to date at this time of writing) still have the issue.

Comment 8

[Julian Descottes [:jdescottes]]

Suspecting this might be linked to incorrect handling of incomplete requests. With the current work from Bomsy, we should be able to get proper response headers to the frontend as soon as the response starts arriving, so this might fix this.