1848440 - Scrolling YouTube Taste Profile page causes unresponsive content process after enough slow scrolling

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Ashley Hale [:ahale]]

Attachment: Screenshot of youtube music after tasteprofile page stops working and is dragged out to a separate window

STR:

1. Open https://music.youtube.com/tasteprofile with a logged in Google account, but not youtube music subscription (may be important?)
2. Scroll down slowly for several minutes and occasionally click an artist, autoscroll may work for this but I didn't try that method, clicking artists may not be necessary either.
3. Eventually page stops scrolling, and appears incorrectly rendered (missing images, blank areas at the bottom, and scrolling back up does not bring back the earlier content, as if WebRender got a displaylist but no new displaylists are being submitted from this point on).

Observations:
4. Page does not resize when window is resized (content area does not change size).
5. F5 does not refresh the page.
6. After a delay a notice appears saying "This page is slowing down Nightly. To speed up your browser, stop this page. Stop",.
7. Dragging the tab into/out of a window causes it to go completely blank but that notice stays.
8. Clicking the Stop button causes the page to reappear but not work properly (buttons for showing interest in an artist do not get a checkmark when clicked).

Comment 1

[Andrew McCreight [:mccr8]]

Do you have a crash report from about:crashes? This sounds more like the content process being unresponsive than a crash per se. Maybe a profile would be useful here?

Comment 2

[Ashley Hale [:ahale]]

No crashes in about:crashes.

Profile once it stopped working - https://share.firefox.dev/447J1Qu

Comment 3

[Andrew McCreight [:mccr8]]

It looks like the time is being spent inside the JS callback for the intersection observer. Maybe the script has some kind of quadratic behavior.

Comment 4

[Ashley Hale [:ahale]]

It may be crucial to actually select some of the artists when doing the STR I mentioned, which expands the list with additional rows, if I simply slow scroll to the bottom (either via mousewheel or autoscroll) it doesn't lock up. But if I interact with it normally it does.

Comment 5

[Gregory Pappas [:gregp]]

This is not a recent regression, I am able to reproduce in a build from 2021-05-01. To reproduce the issue, you do need to select an artist every once in a while. The issue does reproduce when autoscrolling.

Comment 6

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

This bug was moved into the Performance component.

:ahale, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 7

[Ashley Hale [:ahale]]

Attachment: about:support text

Comment 8

[Ashley Hale [:ahale]]

Attachment: about:support raw data

Comment 9

[Ashley Hale [:ahale]]

Attachment: about:support raw data (json)

Comment 10

[Ashley Hale [:ahale]]

Attachment: about:support raw data (json) edited to add closing }

I tried copying the about:support raw data twice but every time it ends up being invalid json due to a missing } at the end, I've downloaded the attachment and added } at the end and uploaded it again to fix it. Maybe a bug as well.

Comment 11

[Sean Feng [:sefeng]]

The Performance Impact Calculator has determined this bug's performance impact to be high. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on site: Renders site effectively unusable
Websites affected: Major

Comment 12

[Iain Ireland [:iain]]

Have we confirmed that this doesn't happen in Chrome?

As mentioned in comment #27, it looks like we're spending all of our time inside an intersection observer callback. Half of that time is attributed to the get function, which looks like this:

get: function() { return this.__data[c] }

And the other half is spent in append:

appendItems_: function(a) {
    for (var b = []; b.length < a && 0 < this.totalRemainingItems;) {
        var c = this.currentListIndex;
        this.currentListIndex = (this.currentListIndex + 1) % this.itemLists.length;
        var d = this.itemLists[c];
        if (d.length) {
            d = d.shift();
            this.totalRemainingItems--;
            var e = this.get("tastebuilderItemRenderer.selectionFormValue", d);
            e && !this.itemToListIndex_.has(e) && (this.itemToListIndex_.set(e, c), b.push(d))
        }
    }
    this.push.apply(this, ["renderedItems"].concat(fa(b)))
}

I would not expect us to be hugely slower on this code than V8. get is very simple, and from what I can see in this profile we're optimizing it well (eg it's not calling into the VM for megamorphic property lookup). If we're spending half our time there, we must be calling it a lot. There isn't much room for V8 to be faster on it. If there is a qualitative difference between us and Chrome, then my first guess would be that we're triggering the callback more often, not that we execute the callback slower.

Comment 13

[Sean Feng [:sefeng]]

Thank you for looking this Iain.

I am able to reproduce this in Chrome as well. Perf calculator changes this to medium priority given this is also reproducible in Chrome. The keywords remain the same.

Comment 14

[Iain Ireland [:iain]]

If this is happening in Chrome too, then it's almost certainly a website problem, not a problem with the JS engine. Beyond the slow script dialog, which appears to be working as designed, I don't see anything we can do here.

Requesting a second look with respect to webcompat.

Comment 15

[Dennis Schubert [:denschub][OOO, back June 3rd]]

It seems like we're hitting perf issues sooner than Chrome, so this is still a valid WebCompat issue - but not a P1, yeah. I'll reach out to the YouTube team, maybe there's something they can do on their end.

Comment 16

[Calin Tanase]

Attachment: Nightly 128.0a1 (2024-05-30).png

This is still an issue but took long to reproduce.

Environment:
OS: Windows 10
Browser tested: Firefox Nightly 128.0a1 (2024-05-30)