Network markers never end in profile
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
People
(Reporter: bryce, Unassigned)
References
(Blocks 1 open bug)
Details
While debugging bug 1653879 I see some strange profile information shown for the network. https://share.firefox.dev/2CUcnea is the profile showing the behaviour -- the network information in both the content and parent looks odd, with the parent requests seemingly lasting forever.
The following STR are fuzzy -- we don't understand that bug yet, and it may be on YouTube's end, in which case they may adjust the site and break repro.
STR (edit: please see comment 1, these may no longer work):
- Open https://www.youtube.com/watch?v=zCLOJ9j1k2Y
- Set the resolution to 8K on the video
- Wait until the tab starts to jank
- Close the tab
- Start the profiler with the media preset
- Reopen a tab with https://www.youtube.com/watch?v=zCLOJ9j1k2Y
- The tab immediately janks for me (but it's not super clear why, YT appears to being getting stuck in some recursion)
- Capture the profile while the tab is still janking (it may take some time for the capture to complete)
Discussion from Element/Riot that appears relevant:
Michael Hoffmann :brisad
I'm currently reading the network code and getting more familiar with it. I should have a couple of PRs ready soon.
More specifically, I've been looking into how blocked requests can be shown in the UI (for instance, requests blocked by tracking protection).
Today, blocked requests will be shown as never ending in the parent process. That's because the request is aborted by HttpAsyncAborter, which will abort the request but not through nsHttpChannel::ContinueOnStopRequest where the stop marker is triggered. The child process with get the stop marker though. Adding a stop marker in the aborting case solves this.
But that is perhaps what is happening in bryce 's recorded profile. Aborted requests looks like they never finish.
That the requests are duplicated is normal. If a request is initiated by the child, it will send an IPC message to the parent network code which will invoke its AsyncOpen and handle the network request. Then when the response is received the parent get a top marker, and it will also send an IPC message to the child which eventually also sends the stop marker.
julienw
|
Reporter | |
Comment 1•4 years ago
•
|
||
I've reached out to YouTube regarding the bug I gathered the profile from, and they indicated they had an infinate loop in JS that could be causing the jank. They suggest they've fixed it now, so it's possible the STR are no longer valid.
|
||
Comment 2•3 years ago
|
||
I think this has been fixed in bug 1567222.
Description
•