1769377 - Jank when entering miniplayer on YouTube

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Gregory Pappas [:gregp]]

Steps to reproduce:

1. Navigate to https://www.youtube.com/watch?v=_ieNRF9aeTU
2. Enter miniplayer mode by pressing the button in the video player or by pressing the 'i' key on your keyboard.

Actual results: Jank
Expected results: Smooth animation

https://share.firefox.dev/3LaIALD

Comment 1

[Mayank Bansal]

Lots of time spent in Style. cc Emilio

@G: Do you have an adblocker extension? Those typically increase the Style computation time.

Comment 2

[Gregory Pappas [:gregp]]

(In reply to Mayank Bansal from comment #1)

@G: Do you have an adblocker extension? Those typically increase the Style computation time.

Yes, here's a profile with uBlock Origin uninstalled
https://share.firefox.dev/3NhXxwK

Comment 3

[Markus Stange [:mstange]]

Turning off uBlock Origin didn't seems to make much of a difference.
JS call tree with and without

I agree with Mayank, the part that stands out the most is the Style time.
The other part that stands out is History.pushState: https://share.firefox.dev/3wPVnPP / https://share.firefox.dev/3LSt2MZ .

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yeah, each of the restyles is styling 3k elements. So I guess we should look into why and whether we're invalidating too much or something else is going on.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

So locally I don't see half a second jank, but I guess I'm on a reasonably fast machine. I see that taking about 100ms. To be clear, each of the 500ms jank periods is the i keystroke right?

Comment 6

[Gregory Pappas [:gregp]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

So locally I don't see half a second jank, but I guess I'm on a reasonably fast machine. I see that taking about 100ms. To be clear, each of the 500ms jank periods is the i keystroke right?

Yeah, each jank bar is me pushing the 'i' key

Another profile from today's Nightly https://share.firefox.dev/3LN1dWo

Comment 7

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

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Setting S2 for now since it seems the jank is only observable on a low end machine, the original profile result was taken on a two core machine, but as per our telemetry data almost 50% of our users are still on two core machines.

Comment 9

[Daniel Holbert [:dholbert]]

FWIW on my ThinkPad (with Nightly on Ubuntu): when I perform the STR, I usually get a jank bar of around 120-150ms, occasionally a little longer or a little shorter. Here's a profile I just captured: https://share.firefox.dev/3y79VKa

If I perform the STR on the same system using Chrome, their profiler shows me "Long task" red bars that are on the same order of magnitude (e.g. "Long Task took 150.86ms").

So I wonder if there's really a Firefox-specific bug here, or if there's just some substantial amount of work that YouTube is forcing which causes a bit of jank in all browsers?

Gregory, do you see similar results in Chrome? (perceptually and/or via devtools performance recordings)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot of 150ms "long task" in Chrome

Here's where I'm seeing the "long task" in Chrome (notice the tooltip from me hovering that red shaded area). I'm not as familiar with their performance tools, but I think (?) this is roughly equivalent to a red jank bar in the Firefox profiler.

Comment 11

[Daniel Holbert [:dholbert]]

I tried the STR on my Microsoft Surface 3 (also Ubuntu 22.04) which is my "slow machine" (Intel i5-4300U, 2 physical cores, 4 logical cores -- same count as reporter). I'm seeing similar results but proportionally slower:

• Subjectively it feels like there's roughly a half-second response-time when I press i, in both Firefox and Chrome.
• If I capture a profile in Firefox, I see red jank bars with around 280-350ms duration.
• If I capture a profile in Chrome, I see similar-duration "Long task" bars at the top of the Main section, the same area I'm hovering in my screenshot. (e.g. I'm looking at a region right now where it's a 305ms to go from miniplayer to regular, and then 285ms to go back to mini)

(Also, one warning: the very first conversion to miniplayer is sometimes extra-long due to some additional resource loads or something; usually this involves YouTube showing a red progress bar at the top of the viewport. That doesn't always happen, but when it does, it's a bit more time overall to swap modes. So if you happen to hit that version of the mode-switch the first time, I'd ignore that one for the purposes of this bug; it's sort of an outlier, and I've seen it in Firefox as well as Chrome.)

So: based on my testing (admittedly all on Ubuntu) on fast and slow machines, it seems like Firefox and Chrome are on-par with each other here.

Comment 12

[Daniel Holbert [:dholbert]]

And given Comment 11, I think we can at least downgrade the severity here; though really we may want to just close this as not-a-Firefox-bug, pending confirmation from the reporter that they're seeing similar results from Chrome (just as I am).

Comment 13

[Daniel Holbert [:dholbert]]

Here's a script that can be entered in devtools console to capture a benchmark of how long the Shrink/Expand miniplayer actions take, in any browser (taking advantage of the fact that YouTube seems to send an event yt-rendererstamper-finished when they finish rendering):

function go() {
  if (count == 0) {
    return;
  }
  count--;
  let selector = isExpanded ? ".ytp-miniplayer-button" : ".ytp-miniplayer-expand-watch-page-button";
  let actionDesc = isExpanded ? "Shrink" : "Expand";
  let btn = document.querySelector(selector);
 
  let t0 = performance.now();
  btn.click();
  document.addEventListener("yt-rendererstamper-finished",
    function() {
      let t1 = performance.now();
 
      console.log(`${actionDesc} duration: ${t1 - t0}ms`);
      isExpanded = !isExpanded;
      setTimeout(go, timeoutDur);
      }, {once: true}
  );
}
var isExpanded = true;
var timeoutDur = 600;
var count = 20;
go();

This gathers count (20) measurements, automatically clicking the button to switch back and forth, with a cooldown period of timeoutDur (600ms) between each action.

Comment 14

[Daniel Holbert [:dholbert]]

Using the previous script on my Microsoft Surface 3 (Ubuntu 22.04), here are the 20 measurements that I got from Firefox (Fresh profile):

Shrink duration: 922ms
Expand duration: 368ms
Shrink duration: 231ms
Expand duration: 220ms
Shrink duration: 195ms
Expand duration: 193ms
Shrink duration: 188ms
Expand duration: 197ms
Shrink duration: 210ms
Expand duration: 177ms
Shrink duration: 195ms
Expand duration: 189ms
Shrink duration: 200ms
Expand duration: 207ms
Shrink duration: 274ms
Expand duration: 192ms
Shrink duration: 195ms
Expand duration: 196ms
Shrink duration: 195ms
Expand duration: 215ms

vs. Chrome (incognito tab):

Shrink duration: 1063.800000000745ms
Expand duration: 412.29999999981374ms
Shrink duration: 379.59999999962747ms
Expand duration: 244.59999999962747ms
Shrink duration: 285.1000000005588ms
Expand duration: 252.6000000005588ms
Shrink duration: 343.5ms
Expand duration: 245.09999999962747ms
Shrink duration: 300.70000000018626ms
Expand duration: 247.69999999925494ms
Shrink duration: 306.1000000005588ms
Expand duration: 279.79999999981374ms
Shrink duration: 289.70000000018626ms
Expand duration: 402ms
Shrink duration: 343.5ms
Expand duration: 454.79999999981374ms
Shrink duration: 293.5ms
Expand duration: 456.5ms
Shrink duration: 385.80000000074506ms
Expand duration: 404.09999999962747ms

Note that the first measurement is longer (about a full second) for both Firefox and Chrome; this is the "red progress bar" load that I mentioned in comment 11.
After that, it looks like measurements are typically a bit lower in Firefox than in Chrome (but same ballpark).

So this confirms my observations from profiler (note that my benchmark script isn't directly measuring jank, but measuring "click to yt-rendererstamper-finished time", which is roughly the response time for the transition I think).

I'm going to take my results from this script as more-objective confirmation of my earlier interpretation summed up at the end of comment 11 (my earlier assessment was slightly-shaky since it was just based on subjective perception and my suspicion that "long task" bars in Chrome were similar to our jank bars). Given this data supporting the conclusion that Firefox and Chrome are on-par here (with Firefox being potentially better), I think we're safe to close this as not-a-Firefox bug.

Gregory, I'm still curious to see if my comparison holds up for you -- if Chrome seems faster to you, particularly if it measures faster using the script from my previous comment [which can be pasted into devtools console once the video is playing], please reopen or let us know.

Comment 15

[Daniel Holbert [:dholbert]]

Or if you can confirm that Chrome is similarly-bad for you (as I'm seeing), that's great to know too. :)

Comment 16

[Gregory Pappas [:gregp]]

Hi Daniel, thank you so much for the thorough followup! I ran your script from comment 13 and am getting the same results, Firefox is slightly faster, that isn't entirely what this bug report is about though, the main issue I originally saw was that the minplayer animation janked in Firefox, which did not happen in Chrome. It seems YouTube actually removed that animation...so yeah. I still see similar jank when exiting the miniplayer, I'll spin that into a new bug.