Closed Bug 1651416 Opened 5 years ago Closed 5 years ago

Firefox continues freezing after update to 78.0.1

Categories

(Core :: Performance, defect)

78 Branch
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: donley.brian, Unassigned)

References

Details

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

Steps to reproduce:

I have 32 open tabs on firefox 78.0.1 periodically browser becomes unresponsive for a few seconds then becomes responsive.

Actual results:

Browser becomes unresponsive and a message is displayed at the top of my screen informing me 'Firefox is not responding...' the the browser continues in a normal manner.

Expected results:

Browsing should continue normally. Prior to update 78.0.0 I was able to have open 70+ tabs without an issue.

Hi Brian,

Does this happen in latest nightly build? You can download it from here: https://nightly.mozilla.org/

Please test if the issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Can you capture a performance profile using the Cleopatra add-on? You can get more info on how to install and use the Cleopatra add-on (that helps you get the performance profile) by going to:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
https://perf-html.io/

Or you could install the Firefox Profiler (https://profiler.firefox.com/), capture a profile of the issue taking place, then share the profile run and paste the link on this bug?

(Please also note that this add-on works only on FF Nightly, so that means you need to be able to reproduce the issue on Nightly first.)

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Component: Untriaged → Performance
Product: Firefox → Core

FYI here ( https://www.reddit.com/r/firefox/comments/hlvqap/firefox_78_extremely_slow_graphic_performance/ ) is more evidence of a serious issue. Barring a major overhaul of the render system there is some kind of stalling bug happening. It hits me when I scroll pages, they turn white in the uncovered regions and the scrollbar stalls and won't go further. I'm just frustrated like hitting speed bumps waiting for Firefox to come out of brief micro comas that last a fraction of a second.

Intel Iris Pro integrated chipset (5200) and MX Revolution mouse with fast scrolling...

Maybe with a slow scroll speed the problem would be unnoticed. The effect is on many sites. It kind of feels like bottomless sites that want to download content only after scrolling (not enough look ahead) but it happens scrolling up or down and with content that should already be in the browser's content model unless it's dumping parts of its memory because it's starved.

No new plugins, just started in past two or three days. Quitting and restarting seems to make the problem go away for a few minutes. But it comes back.

How can we raise this to Mozilla's attention... it's not a minor bug? Does it require a new issue? Who can word it properly? Why does Mozilla not provide a way out of a bad update (https://www.reddit.com/r/firefox/comments/hvj6xx/disable_update_now_aggression_for_current_bad/) ?

Mick, thanks for reporting this. It's hard to tell what exactly is going on here with the lack of information.

Do you have a reliable way that can reproduce the freeze?

If not, would you mind to use https://profiler.firefox.com/ to capture a profile for the freeze? Just click the addon icon to start the profiler, leave it running (note that it'll degrade the performance), and then you can start opening tabs and browsing normally. Click the icon again once the browser becomes responsive again from a freeze.

Flags: needinfo?(mick.pearson)

Someone in the Reddit thread used the regression tool and thinks they identified the specific build. Unfortunately I can't help a lot, other than to warn Mozilla that its "ESR" package is already using 78, which seems crazy if it's meant to be stable, since 78 has been live for less than 2wks. There is a horrible bug in 78 that Mozilla should be stopping everything to work on. Literally everyone who can should be focused on this right now.

(For me nearly every action in 78 stalls for a half-second to a second. You might not notice it, even though that's a pretty long time. Because I have satellite Internet service I probably notice the latency less since I'm used to some of it, but 78's stalls are unrelated to downloads. Others on all kinds of systems are reporting longer stalls and graphics glitches, so they're better positioned than I am to profile. For me parts of the viewport that are revealed by the scrollbar stay white until the renderer kicks in. And scrolling halts so that it doesn't scroll more than a screen past the white region. I would guess performance is always teetering on the brink. Running the new picture-in-picture feature definitely exacerbates it. Scrolling through YouTube's recommendation wall of thumbnails seems to be difficult for the browser so the effect is more noticeable, but even on static pages scrolling up and down a screen fast can hiccup. This is all the information I can provide since I'm using 77 now. And I wish there was a user-friendly way to do that, but that's another matter)

I do full-time development so in my opinion, I think something on the CPU/system memory side is probably starved. It could be related to memory that backs GPU memory, or it could be a bug out of left field that's just wreaking havoc. It's something very serious whatever it is. It's independent of add-ons and operating systems and low-end and high-end hardware, so it's very possibly effecting everyone in the world, although seems unlikely since developers should have seen it by now.

Flags: needinfo?(mick.pearson)

I'm running build 78.0.2 (64-bit) on MacOS 10.15.5 (32GB Ram, not in swap). I have this same issue.

I have maybe 10 tabs open. When cycling tabs, I get a pause to renew a (previously loaded and rendered) tab, as if this was the first time FF was loading/rendering the tab. The pause is about the same as a cold start of FF.

I also get random pause/lockup for about 5 seconds on the browser itself (Including spinning beachball).

Tried to run mozregression-gui, but to be honest, it's a bit laborious to reproduce on a new build, so that wont be an option right now.

It appears that FF just dumps entire tabs from memory then decides to re-render it when the tab becomes active again.

I have a suspicion it might be related to gmail based on eyeballing about:performance, as the only trend I could spot by eye was the task for the gmail tab disappearing, then pause, then reappearing. Unsure if this pattern exists for other sites.

What else can I gather (Keep in mind, I have a somewhat restrictive environment, so I cannot run many tools).

A Reddit user (BornOnFeb2nd) thinks this (below) is the specific nightly build that introduces the misbehavior. Chances are they're right. It just seems like (intentionally or unintentionally) the change is being very stingy with resources, whether that's to have a smaller system footprint or because some bug is hogging said resources. (I have 3 windows with possibly hundreds of tabs, just in case there is some truth to having multiple tabs contributes to noticing the effect. Many have reported being users who seem to leave open tabs--but they shouldn't have any overhead if just dormant--but you never know. A release a while back broke pages with many GIFs... opening a menu of smileys made my fan system kick into overdrive, that was since fixed, but maybe FF is experimenting with GPU stuff that's misbehaving under certain conditions.)

app_name: firefox
build_date: 2020-05-31
build_file: C:\Users\User\.mozilla\mozregression\persist\2020-05-31--mozilla-central--firefox-78.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/05/2020-05-31-21-42-11-mozilla-central/firefox-78.0a1.en-US.win64.zip
changeset: e4b11f027efc1f8c2710ae3f52487a8f10a8fb39
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4b11f027efc1f8c2710ae3f52487a8f10a8fb39&tochange=bc973d369db58faf254ddcef201089dc28e6d3be
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Mick, I still think a profiler could be useful because it should be able to reveal what the browser is doing for those half seconds stalls. I mean, if you can collect one, that'd be great.

Do you mind visit about:config , click Copy raw data to clipboard and paste the information here?

Flags: needinfo?(mick.pearson)

After updating to 78.0.2 I didn't have any problems. Then after reloading Windows 10 and version 78.0.2 I still don't have any problems. I will continue to reinstall all of my other programs and continue testing in between added programs to continue to verify that there isn't a problem. If I develop a problem I will uninstall the last program, retest to see if I had an offending program.

(In reply to Brian from comment #9)

After updating to 78.0.2 I didn't have any problems. Then after reloading Windows 10 and version 78.0.2 I still don't have any problems. I will continue to reinstall all of my other programs and continue testing in between added programs to continue to verify that there isn't a problem. If I develop a problem I will uninstall the last program, retest to see if I had an offending program.

This indicate the Reddit reports are a different problem. I nominated this ticket since it was close to the problem, but it's possibly a separate matter. I do think a new ticket with very high priority and alarmist language is appropriate at this time.

(In reply to Sean Feng [:sefeng] from comment #8)

Mick, I still think a profiler could be useful because it should be able to reveal what the browser is doing for those half seconds stalls. I mean, if you can collect one, that'd be great.

Do you mind visit about:config , click Copy raw data to clipboard and paste the information here?

I don't have that option in my Firefox. If Firefox had a simple system to switch back and forth between releases it would be much easier for users to help you guys diagnose problems and it would be a solution in times like this. Since switching to 77 is made so difficult there's no turning back for us. I realize maybe with third-party tools this is possible but that's asking too much from users who don't do development.

Is there a code-commit page somewhere for BornOnFeb2nd's nightly build? It seems like some change in that commit is the culprit. We'd need to know how broad those changes are. If we had eyes on that code I don't mind taking a look at it.

Flags: needinfo?(mick.pearson)

(In reply to Mick P. from comment #10)

Do you mind visit about:config , click Copy raw data to clipboard and paste the information here?

I don't have that option in my Firefox.

Sean made a mistake here, the address is about:support.

Is there a code-commit page somewhere for BornOnFeb2nd's nightly build? It seems like some change in that commit is the culprit. We'd need to know how broad those changes are. If we had eyes on that code I don't mind taking a look at it.

See https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4b11f027efc1f8c2710ae3f52487a8f10a8fb39&tochange=bc973d369db58faf254ddcef201089dc28e6d3be

Flags: needinfo?(mick.pearson)

Over in Reddit F4k3Acc says:

"I tried to use Firefox Developer Edition which is 79.0b9 version and the issue is fixed. Guess now we need to wait for the update. According to https://wiki.mozilla.org/Release_Management/Calendar Firefox 79 should be released around 2020-07-28."

Maybe someone quietly patched it already? (Assuming everyone on Reddit is experiencing the same bug.)

(In reply to Asif Youssuff from comment #11)

(In reply to Mick P. from comment #10)
Sean made a mistake here, the address is about:support.

swordofmoonlight.net/holy/Firefox.zip is my about:support output.

Flags: needinfo?(mick.pearson)

This sounds resolved if it is no longer reproducible in 79. I will mark it as resolved, but please reopen if that's not the case. Also please attach a performance profile if it occurs again so we can look into the details more closely. The instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem. Thank you.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

It would still be nice to find out what caused it. If anybody wants to collect a profile of the problem, that would be very useful.

(In reply to Denis Palmeiro [:denispal] from comment #13)

This sounds resolved if it is no longer reproducible in 79. I will mark it as resolved, but please reopen if that's not the case. Also please attach a performance profile if it occurs again so we can look into the details more closely. The instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem. Thank you.

You don't think you're jumping the gun to decide this before 79 is released? We still don't know if everyone is experiencing the same effect and this report is anecdotal.

Mick, I would very kindly suggest it would assist everyone here if you are able to provide a performance profile when you have a minute. It would be much easier to isolate the problem, as your report is currently anecdotal as well. I am unable to replicate your issue either.

(In reply to John from comment #16)

Mick, I would very kindly suggest it would assist everyone here if you are able to provide a performance profile when you have a minute. It would be much easier to isolate the problem, as your report is currently anecdotal as well. I am unable to replicate your issue either.

Yes all reports so far are anecdotal. Please see the Reddit link if you haven't already. Many have been asked to profile and so on, and some have provided reports. We all realize it would be helpful.

I'm waiting for 79 to be released to the general public. If anyone knows if it's already out please let us know. The Help->About window in FF doesn't say anything about what release it has in the chamber.

Following up, after using 79 for few days I didn't notice anything, until today smooth scrolling short distances on YouTube and other sites feels drunk, and when I scroll on a modest page there's an occasional micro stutter suggesting sites like YouTube (more graphics heavy?) are constantly doing this stutter.

I think there's now performance gremlins in FF that someone should be looking into. The stutter is there (at least today) immediately after quitting/starting a new FF instance. I haven't noticed this in the previous couple days with 79. I can't tell you what that means other than nothing has changed. This web page scrolls fine. It's obviously a performance thing. I would try to profile it but this ticket is closed, so I'm just following up with my 79 experience.

Please link to a new ticket if someone's made one.

I'm also having occasionally jerky responsiveness on 79.0 on linux. I haven't managed to record a profile of it happening just yet since it's typically a short period of pauses, sometimes exceeding 1s, and then it will go away for a while, but I will post one if I can get it right while it's hanging.

https://bugzilla.mozilla.org/show_bug.cgi?id=1658571 is a new ticket. I thought I'd already cross linked these.

See Also: → 1658571
You need to log in before you can comment on or make changes to this bug.