Bugzilla

I looked into the profile attached in comment 11 and based on what I can see at the moment:
- the parent process isn't that busy and there isn't any jank and so I would expect the browser UI (e.g. opening the app menu) should be lagging.
- the extension process does also seem to be using almost no CPU, seems to be almost always idle.
- on the contrary the content process where youtube is playing is quite busy (which isn't super surprising, given that it is the process where most of the work related to what the youtube page is doing does actually happen).

All these seem to be the case also in the other two profiles attached to comment 4 and comment 5 (beside the fact that the in these two profiles there is a red bar that suggest there was a jank, but at the same time the activity traced in the same time slice doesn't seem to reflect that jank and it may be some kind of issue in the data got from the profiler).

Another details that I did notice in this last profile (but not in the other two) is an "hole" in the "Extension Suspend" markers around the time where based on the screenshot I think that stream got stuck (between ~107s and ~130s), the markers seems to have been received and handled with a pretty regular timing (up to that point, where the stream seems to be suspiciously getting stuck too).

And so, at least at the moment based on the details I do have, my theory is that we may be hitting:

- an issue that is making the request intercepted by the extension to be suspended and to never resume (under this condition there wouldn't be any "Extension Suspend" marker, because [those marker are added when the request is resumed from ChannelWrapper::Resume](https://searchfox.org/mozilla-central/rev/4e59e46055338941eddf1bff0a9c8da05fdba94b/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#267-273)).

- or some other issue that is making the http request to get stuck and maybe not even triggering any webRequest listener because it got stuck before any of the steps that would be notified to the extensions

I tried to "force" the first of these two issues with a minimal test extension (one that would suspend any webRequest intercepted once I click on its browserAction button, so that I could let the youtube stream and live chat to work as expected until I trigger the extension explicitly) and the results was that:
- the stream and livechat got stack a few seconds after the extension has started to suspend any webRequest and leave it suspended
- the video element started to show a loading spinner

But in the screenshots collected in the profile attached to comment 11 I don't see the same spinner rendered on top of the video element when the stream got stuck, which makes me think that the minimal test extension wasn't reproducing the exact same issue.

I looked into the profile attached in comment 11 and based on what I can see at the moment:
- the parent process isn't that busy and there isn't any jank and so I would expect the browser UI (e.g. opening the app menu) to not be lagging.
- the extension process does also seem to be using almost no CPU, seems to be almost always idle.
- on the contrary the content process where youtube is playing is quite busy (which isn't super surprising, given that it is the process where most of the work related to what the youtube page is doing does actually happen).

All these seem to be the case also in the other two profiles attached to comment 4 and comment 5 (beside the fact that the in these two profiles there is a red bar that suggest there was a jank, but at the same time the activity traced in the same time slice doesn't seem to reflect that jank and it may be some kind of issue in the data got from the profiler).

Another details that I did notice in this last profile (but not in the other two) is an "hole" in the "Extension Suspend" markers around the time where based on the screenshot I think that stream got stuck (between ~107s and ~130s), the markers seems to have been received and handled with a pretty regular timing (up to that point, where the stream seems to be suspiciously getting stuck too).

And so, at least at the moment based on the details I do have, my theory is that we may be hitting:

- an issue that is making the request intercepted by the extension to be suspended and to never resume (under this condition there wouldn't be any "Extension Suspend" marker, because [those marker are added when the request is resumed from ChannelWrapper::Resume](https://searchfox.org/mozilla-central/rev/4e59e46055338941eddf1bff0a9c8da05fdba94b/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#267-273)).

- or some other issue that is making the http request to get stuck and maybe not even triggering any webRequest listener because it got stuck before any of the steps that would be notified to the extensions

I tried to "force" the first of these two issues with a minimal test extension (one that would suspend any webRequest intercepted once I click on its browserAction button, so that I could let the youtube stream and live chat to work as expected until I trigger the extension explicitly) and the results was that:
- the stream and livechat got stack a few seconds after the extension has started to suspend any webRequest and leave it suspended
- the video element started to show a loading spinner

But in the screenshots collected in the profile attached to comment 11 I don't see the same spinner rendered on top of the video element when the stream got stuck, which makes me think that the minimal test extension wasn't reproducing the exact same issue.

I looked into the profile attached in comment 11 and based on what I can see at the moment:
- the parent process isn't that busy and there isn't any jank and so I would expect the browser UI (e.g. opening the app menu) to not be lagging.
- the extension process does also seem to be using almost no CPU, seems to be almost always idle.
- on the contrary the content process where youtube is playing is quite busy (which isn't super surprising, given that it is the process where most of the work related to what the youtube page is doing does actually happen).

All these seem to be the case also in the other two profiles attached to comment 4 and comment 5 (beside the fact that in the other two profiles there is a red bar that suggest there was a jank, but at the same time the activity traced in the same time slice doesn't seem to reflect that jank and it may be some kind of issue in the data got from the profiler).

Another details that I did notice in this last profile (but not in the other two) is an "hole" in the "Extension Suspend" markers around the time where based on the screenshot I think that stream got stuck (between ~107s and ~130s), the markers seems to have been received and handled with a pretty regular timing (up to that point, where the stream seems to be suspiciously getting stuck too).

And so, at least at the moment based on the details I do have, my theory is that we may be hitting:

- an issue that is making the request intercepted by the extension to be suspended and to never resume (under this condition there wouldn't be any "Extension Suspend" marker, because [those marker are added when the request is resumed from ChannelWrapper::Resume](https://searchfox.org/mozilla-central/rev/4e59e46055338941eddf1bff0a9c8da05fdba94b/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#267-273)).

- or some other issue that is making the http request to get stuck and maybe not even triggering any webRequest listener because it got stuck before any of the steps that would be notified to the extensions

I tried to "force" the first of these two issues with a minimal test extension (one that would suspend any webRequest intercepted once I click on its browserAction button, so that I could let the youtube stream and live chat to work as expected until I trigger the extension explicitly) and the results was that:
- the stream and livechat got stuck a few seconds after the extension has started to suspend any webRequest and leave it suspended
- the video element started to show a loading spinner

But in the screenshots collected in the profile attached to comment 11 I don't see the same spinner rendered on top of the video element when the stream got stuck, which makes me think that the minimal test extension wasn't reproducing the exact same issue.