1999199 - Resizing the browser window with https://data.firefox.com/dashboard/hardware open uses 100% CPU load for about 20s

Status: NEW

(Data & BI Services Team :: Other, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:146.0) Gecko/20100101 Firefox/146.0 ID:20251028215909

Opening the DevTools inspector with the Cmd+Option+I shortcut on https://data.firefox.com/dashboard/hardware causes 100% CPU load for about 20s. Until then a user also has to wait until anything is displayed in the inspector (or any other) panel. The content process is frozen during this time.

Here a recorded Gecko profile: https://share.firefox.dev/47zH7Nz

The flame chart shows that we spent nearly all the time in SVGGeometryElement.getPointAtLength, which itself is part of a request animation frame callback.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As Julian mentioned to me this is actually not a DevTools issue but also happens when resizing the browser window. When DevTools is opened this is what basically happens with the content area. It's not visible when opening DevTools in a separate window.

Not sure if this is an issue with the page itself or us not handling it correctly. CC'ing Emilio in case he has an idea.

Comment 2

[Julian Descottes [:jdescottes]]

Not sure if this is an issue with the page itself or us not handling it correctly

FWIW, I see the same with Chrome.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks for this extra check, Julian. I should have done this myself.

So it looks like a general issue with the page then. I assume the firefox.com product is the right one then?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The problem here is actually that the page registers 11 event listeners for the resize event on the HTML element. All of them reference the exact same code in https://data.firefox.com/static/js/components/containers/ChartContainer.jsx:

    // Set the chart size state based on the real, rendered parent container.
    setChartSize = () => {
        const {width, height} = this.getChartSize();

        this.setState({
            chartWidth: width,
            chartHeight: height,
        });
    }

Having only a single event listener active works just fine and resizes the graphs respectively with a way lower CPU load and just within 3.5s (Gecko profile). If there is further room for improvements I'm not sure and graphic folks might be able to answer.

But why are we registering 10 more listeners which basically run the exact same code and probably compete with each other?

Steve, could you please take a look? Thanks!

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Regarding the heavy path on SVGGeometryElement.getPointAtLength we seem to spend most of the time in mozilla::gfx::FlattenBezier (https://share.firefox.dev/3Xua4o9).

Comment 6

[Steve Jalim]

Hi Henrik

www.firefox.com is the component specific to www.firefox.com but not any other domains. I've switched the component to a Data Science one that might be a better fit and will reach out within Slack to see if I can get some eyes on this ticket.

FWIW, in the future, my team looks like it will be owning this project, but it's early days and I've only looked at the codebase to determine its infra requirements for now. I'll see if I can find someone to help resolve the actual application issue in the meantime.

Cheers
Steve

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hi Steve, I wanted to check back with you if there might be resources to get this issue investigated and fixed. Thanks.

Comment 8

[Steve Jalim]

Hi Henrik - no movement yet, I'm afraid. My team is very busy and the overall ownership angle still needs to be agreed.

Comment 9

[Elle Solomina (she/her)]

There's definitely not fixed and bug still exist. I test it on Honor 50 lite and page completely unusfull, additionaly all other pages in Firefox Android slow down significantly