1678621 - Firefox 82 freezes constantly when using browsersync / responsive design mode

Status: UNCONFIRMED

(DevTools :: Framework, defect, P3)

Description

[coder]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Firefox 82 on OsX 10.15. I use browsersync to inject css changes in my pages when developing, at the same time working in responsive design mode. Since the issue only arises after some hours of work, I didnt try to exclude the responsive design mode yet.

Actual results:

Since Firefox 82: When using browsersync to inject css changes in my pages when developing, I get random freezes. Firefox becomes completely unresponsive, spinning beachballs, takes over 100% of processor. Freezes take about 20 secs, and occur almost every couple of minutes.
It tends to occur after 3/4 hours of work. I do use the responsive design mode in combination with browsersync. Restarting the browser solves it for some time.
Disabled all add ons to make sure it wasnt any add-on.

Expected results:

Before FF 82, there was'nt any problem with this setup.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[coder]

To be overcomplete: The web developer inspector window is open as well when I experience this. :)

Comment 3

[Brad Werth [:bradwerth]]

Thank you for filing. It would be helpful if you could engineer a testcase that would demonstrate this when run in an RDM window without user input. Is that possible?

When this occurs, and if you are able to get control of your browser, please open a tab to "about:memory" and save a memory report, and add that report to this bug. Use the "anonymize" box if you are concerned about sharing the URLs of your open tabs.

Comment 4

[coder]

Attachment: memory-report.json.gz

This is a memory report from when Firefox was freezing up, when using the RDM. I am not sure what you meant with 'no user input', but I hope this might help you. If you need a different report, please feel free to let me know, and i'll generate one.

Comment 5

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

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

For more information, please visit auto_nag documentation.

Comment 6

[Brad Werth [:bradwerth]]

Thank you for the memory report. It is helpful. I compared your memory report to a non-scientific baseline of a fresh browser with one tab with the Inspector and RDM open, recorded right after launching the browser, and also compared against a memory report of the same setup after about 30 minutes with a bit of navigating around. The two recordings of my browser were essentially the same, so I'm obviously not replicating the bug. But this bug is about lots of css injection, which my test doesn't replicate. This is what I'm talking about as far as getting a testcase that can reproduce the bug without user input.

Anyway, comparing my 30-minute memory recording to your memory recording, the big additions in your recording are:

• 500 MB -- realm([System Principal], DevTools (Module loader)): this seems that a module load is not completing or is being duplicated somehow.
• 300 MB -- strings: includes some large allocations but also 19 copies of the jQuery v3.5.1 source, and 16 copies of Drupal core. Again, this is an indication of multiple reloading of modules.
• 800 MB -- heap-unclassified: this is an area where our allocations aren't labelled. This may be browser-internal objects that are duplicated in the module loading process and aren't cleaned up properly when the module loading doesn't complete properly.

And there's also 1 GB of memory being used by js-main-runtime, which would seem to indicate that there is lots of active script running.

So I think the next step is to get a repeatable testcase, if possible. Is there a way you can setup a site or file that we could use to reproduce the problem? I'm also curious if this problem happens for you without RDM running.

Also needinfo'ing Alex in case he has thoughts about the memory report and what might be causing that pattern of allocations.

Comment 7

[Alexandre Poirot [:ochameau]]

I think this is the first time I hear about a performance issues specific to CSS.
But we have various bugs opening reporting performance issues after many reload. Various of out tools probably let things allocated after each reload.

Comment 8

[coder]

Attachment: memory-report_no-rdm.json.gz

Hi Brad, Alexandre,
thank you already for looking into this issue. I worked a day without RDM, and the freezing also occurred there. I made a memory report during that freeze as well, maybe this gives more insight, maybe it just shows the same. To be clear, this was with browsersync refreshing the css, and multiple manual refreshes as well. I'll try and do a day without browsersync, see if that makes a difference. As for the testing environment, I'll look into that, but not sure yet as both these sites are still in development.

Comment 9

[coder]

Attachment: memory-report_no-browsersync.json.gz

And for the sake of being complete, also a report from a day of work without browsersync, but with only manual refreshes. After a few hours, I experienced a freeze yet again, but it felt like it took longer to occur.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

moving to framework as it looks like a broader issue and reporter reproduced without RDM