1524297 - Combine flexbox and box model highlighter is causing huge memory usage

Status: RESOLVED WONTFIX

(DevTools :: Inspector: Layout, defect, P2)

Description

[jevus.d]

Attachment: 2019-01-31 10_29_31-Windows Task Manager.png

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Using nightly 67.0a1 (2019-01-31) (64-bit)

Load page with 1200 list items in a div.
Open developer tools.
Move mouse across the divs and lists.
Firefox highlights the boxes pink and then freezes.
Memory of tab increases and doesn't stop.

Actual results:

Tab went up to about 8GB of memory usage and then I closed it by killing the process in task manager.

Expected results:

It should not have frozen the developer tools.

Comment 1

[jevus.d]

This bug happened after updating nightly yesterday.
Before the update the developer tools had no issues with handling 1000s of div list items.
Before that update the tools also did not have the pink box highlighting.

After the update and with the introduction of the pink highlighting is when the developer tools started freezing.

Comment 2

[jevus.d]

Here is a video of the tools freezing. https://streamable.com/hiqug

Comment 3

[Damira Akh]

Build ID 20190131093752
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

I was not able to reproduce this, Can you give me the link to the website if it's accessible to the public.
Thank you.

Comment 4

[Julien Wajsberg [:julienw]]

From the bug description it looks like the reporter was working with the Inspector, not the Memory tool. => moving to the appropriate component.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Andrei, can someone from your team try and find the regression window? Looks like a recent issue in 67. Thanks!

Comment 6

[jevus.d]

(In reply to Damira Akh from comment #3)

Build ID 20190131093752
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

I was not able to reproduce this, Can you give me the link to the website if it's accessible to the public.
Thank you.

Hi Damira,

It's an internal site. I tried to strip the identifying information and I've attached the HTML.

Note: the javascript that loaded the 1200 divs did not insert new lines after each list item div.
I added a new line for each generated div and that seemed to help a bit - the memory footprint still grows larger and larger but instead of the site being totally unresponsive it now has a 1-2 second lag while highlighting the elements in the developer tools.

If you want to replicate the original issue then you'd need to strip the new lines dividing the 1200 list item divs and make it into one giant line.

Comment 7

[jevus.d]

Attachment: test page.html

This html file has the 1200 list item divs separated by a new line.
The original did not have new lines - it was all one giant line of 1200 list items

Comment 8

[jevus.d]

Attachment: 2019-02-06 14_46_31-Title - Firefox Nightly.png

To replicate, open dev tools and inspect the list item container so the list items are visible.
Then just move your mouse back and forth over a few lines and watch the memory usage go up.

Comment 9

[Gabriel Luong [:gl] (ΦωΦ)]

Thank you for the bug report. I was also able to reproduce this on mac. This seems to be caused by the combined flexbox + box model higlighters.

@jevus.d, a quick fix for your local development using nightly would be to go to "about:config" and toggle off "devtools.inspector.flexboxHighlighter.combine". We are currently testing a combine flexbox + box model highlighter in nightly only which is why you are experiencing the issue, and your test case has been super useful so extra thanks for that.

Comment 10

[Gabriel Luong [:gl] (ΦωΦ)]

Clearing the needinfo for a regression window since I have been able to replicate the issue and figure out the cause.

Comment 11

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

This isn't fixed with Brad's method but changing devtools.inspector.flexboxHighlighter.combine to false gives us our highlighter performance back.

I'm not sure why performance is so terrible on that particular page but I will look into it.

Comment 12

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Performance profile

https://perfht.ml/2E5jzlU

Comment 13

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Since landing bug 1523335 the memory usage appears to be much better but the highlighter is still slow due to drawing so much information on a canvas.

When bug 1527282 lands, which gives a slight improvement we should test this again.

Comment 14

[Patrick Brosset <:pbro>]

The feature that consumes the memory is only enabled in nightly and dev-edition right now. So this problem will not reach the release audience.
The feature has, so far, received mixed signals. So we are not going to let it ride the trains as is any time soon.
It is likely that we either remove it, or rework it in a way that the memory characteristics will be very different.
So, no need to track firefox-67 here.

Comment 15

[Patrick Brosset <:pbro>]

We are removing the feature in bug 1536096, so no need to fix this memory consumption problem.