User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

I'm here specifically because I cannot find a pattern or dependably reproduce hanging at will, but I want to get this out there because it began immediately after update to FF89 without previous issues. Sorry about the vagueness but subjective description is all I have right now.

Freezing is intermittent, but I haven't found equivalent complaints online and will continue to look for clues that define circumstances. Every evidence I've gathered has been disproved trying to reproduce circumstances.

FF will freeze at any given moment, not associated with any particular site, but I found two that hang frequently while still intermittent, IMDb and Arkadium games. Ironically, this form completion hung when I created a new tab to check Arkadium spelling, and has happened twice while creating new tabs. The only commonality seems to be interactivity triggering a hang. Another unproven circumstance is noticing the hang during a page's "spinner" presentation, again, perhaps random just because I just happen to notice it while waiting for a spinner to indicate rendering is complete, but usually after I've touched the mouse with the cursor over the FF program.

Actual results:

Using IMDb as one popular example, the home page starts loading and a search field appears at the top early in the render. I begin entering a search term but before finishing the program freezes mouse and keyboard interactivity. The OS is busy but still available after getting the mouse moving. FF is found hovering around 50% CPU but never resolves and needs to be killed and relaunched to continue. Relaunch always seems to work okay, reloading already-open tabs and returning normal functionality, in the case of this form not even losing previous content, so I feel the problem is related to circumstance and not absolute code or discrete events.

Expected results:

Basic mouse or keyboard interaction, render speed, or network availability should be irrelevant beyond a final page load success or fail. This goes beyond that though, even freezing while creating a new home page tab. I've seen many sites that don't handle incomplete code well and need a refresh to interact with, but this is something new and violent that began immediately after FF89 update.

Workaround: kill and relaunch returns working as expected.
Trigger: haven't found any specific event, but feels worse when FF is busy
Addons: without result tried safe mode, then refresh, unloading and replacing a single bookmark extension, but no joy.

Lacking concrete evidence, I can only say this feels like an old-school timing thing, like FF has trouble safely queueing events. Again, attempts to whittle down circumstance has proven not repeatable, and I have relaunched three times during my time completing this form. The computer in question remains stable with other applications on eOS, and alternative browsers like Chrome aren't suffering these issues.

The Bugbug bot thinks this bug should belong to the 'Firefox::Session Restore' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Restoration works fine, but will avoid messing with BugBot categorization unless proven need.

Hey Optional,
I'm trying to reproduce this on the latest versions of Firefox Nightly 91.0a1 (2021-06-09), beta 90.0b5 and release 89.0 but no freezes encounter yet.

Can you try using a new profile for a few days? You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Hi Andrei
I will attempt a second profile later today, but for now I'll paste the log I've been keeping since I upped to 89. I can't promise working with nightly builds, but I will consider that as well once I catch up. Note that 89 is the version loading through eOS AppCentre, so I'll probably have to work through another package handler for your request.

Some common denominators so far:

• almost all involved mouse actions
• many sites, loads pages ok on relaunch, even links or tabs selected but not yet rendered
• don't see any connection to bookmarks, tested with a bookmark add-on disabled but no improvement
• doesn't like loading up on tabs like previous version, used to open tabs until slowed, relaunch to clean house, but can't now
• I never lost FF before unless it bogged to immobile with too many tabs, so I assumed that was RAM or resources, but after 89 see below

A log on the Fox Fire:
Jun05

• freeze scrolling with mouse wheel while still loading ads
• freeze switching tabs with video playing
  Jun06
• freeze data entry field after switching tabs
• freeze mousing into page elements while waiting for ad load status
• freeze selecting menu button with page loading
  Jun07
• freeze waiting for content spinner
• freeze opening four shortcut tabs in succession
• freeze mousing while rendering page, only mouse motion remained and full OS reboot required
• freeze switching pages with bookmark, with status loading ads
• freeze switching tabs during page load, partial tab progress highlighted
• freeze after relaunch, "waiting for" status switching tabs as if still trying to switch tabs from before the hang
  Jun08
  Crash report: sent, first time I've ever seen that dialogue
• reordering tabs while tabs loading
• freeze page load content spinner

• relaunched to new active tab ad page I don't even recall selecting, might have hit an ad by mistake
  Jun09

• freeze clicking into search field while page rendering
• freeze on photo link selection, link open and active after relaunch
• freeze during ad video load, came back after a long time gap, no hang
• freeze watching video with about 15 fresh tabs opened, image stopped first, then sound ten seconds later, then hang

• mouse click test of alternative tab selection was highlighted after relaunch

• freeze typing in bookmark search field, tab state not noted

Okay, new profile up.
Am I to avoid importing bookmarks or add-ons to avoid corrupting the clean slate?

Three freezes the first evening of introducing the blank profile. I didn't import boomarks or add-ons. I will continue until I confirm a nightly install, but I'm pretty sure the blank profile is a dead end.

Two more freeze with fresh profile, switching to nightly.

Freezing has stopped with v91.0a1. A couple of days with it.

I won't elaborate on other wonkiness, but Nightly is great when I expected it to be horrific. Nightly behaves worse than surfing 89, but anything resembling bogging down or failing to load is typically recoverable using the mouse. Nightly is obviously a different beast than whatever passed for 89. With some experience, I now sense something is going South and a quit/relaunch usually fixes it with a clean slate.

Should I try to elaborate on every little thing? I could, but it would be ten little things per day and no longer directly related to my freeze problem.

Are you familiar with using pstack? If so could you get it to a trace of all the unresponsive stacks? If you're not familiar, gselvo could you help out here and provide guidance on how to collect this information?

No/I'll try/more help required:
Installed pstack; don't know how to proceed though. Other busy pids give a response similar to the example below:

• do I need command output to a file?
• exact syntax please, if you know what I need
• would you like to see reports from v89.0, v89-untainted profile, or nightly? Been playing with all three but considering deleting v89-untainted because it added nothing to the conversation.

skyhook@backhoe:~$ sudo pstack 2335
2335: /usr/lib/firefox-trunk/firefox-trunk
(No symbols found)
crawl: Input/output error
Error tracing through process 2335

Is the trace an on/off loggin thing, or parsing system logs from a moment past? I don't have a mental model for what's happening with the examples I saw on the web.

One other way to solve this is to force Firefox to generate a crash report when it's hung, then submit it. The next time you encounter a hang do the following:

• Find out the pid of the Firefox main process, you can go to the about:processes page when it starts and write it down, it will be the first process shown in the list
• When you experience the hang open a terminal and execute the following command replacing <pid> with the Firefox main process pid:
  kill -ABRT <pid>
• Firefox will terminate and the crash reporter should pop up, submit the crash, then reopen Firefox
• Go to the about:crashes page and look for the last submitted crash report, post the link here so we can have a look

Will try crash reporter, sounds more user friendly.

That previously mentioned Jun08 incident is already waiting, the only time I've ever seen the crash reporter as it popped up on its own. That particular incident was a freak show, as if millions of mouseclicks suddenly cried out in terror and were suddenly silenced, so it may be pointless:

https://crash-stats.mozilla.org/report/index/1ae9e74e-dab4-4b63-8f40-c4b800210616

https://crash-stats.mozilla.org/report/index/05a1151f-4e51-4dbc-a39d-75aa90210617

This crash report is showing WebRender hanging in draw_perspective_spans, like bug 1712561 comment 18.

We have some shutdown hangs with very similar stacks to this one, see this query. Most of them seem to be happening on 89. If the main process got stuck it makes sense that those would be reported as shutdown hangs but I'm worried that the issue might be more widespread (see this thread).

Found another thread. I'm engaging with the posters to see if we can get more info about this.

Also filed bug 1716946 to make sure this kind of stuff doesn't fly under our radar. This kind of stuff could have been caught earlier.

Bumping to S2 because we're finding many reports of this spread through various bugs, and this is in release, on a smaller user population, so this might be scarily common.

I'm also affected. Here is a crash report: https://crash-stats.mozilla.org/report/index/bp-7c3f8479-aee8-4d44-8b43-a8f870210617

Bug 1716160 and bug 1715829 sound like the same problem, but there's too little info on those bugs to reliably close them as duplicates. I've pinged the reporters to see if they can report here with more info.

(In reply to Gabriele Svelto [:gsvelto] from comment #22)

Bug 1716160 and bug 1715829 sound like the same problem, but there's too little info on those bugs to reliably close them as duplicates. I've pinged the reporters to see if they can report here with more info.

Yes. I think it's the same bug. I was first reporter of this bug (1716160). Freezes disappeared after update to FF 90 beta.
I don't know what additional info i can provide. Only can say that i have videocard Mobile GM965/GL960 Integrated Graphics Controller on very old laptop (13 years). Maybe this problem caused by WebRender + video drivers.

Valeriy, are you able to try to find the change that fixed the problem using mozregression?

Have upgraded to 89.0.1 64bit from eOS AppCentre. Will continue to post crash links unless directed otherwise.

13yrs sounds about right:
Dell Latitude D830
Adapter Vendor ID: NVIDIA Corporation (0x10de)
Adapter Device ID: G86M [Quadro NVS 135M] (0x042b)
Driver: NVIDIA 340.108

Started feeling invincible, but:
https://crash-stats.mozilla.org/report/index/0142e2a5-80e0-4fb0-9b56-d99e60210618#tab-details

https://crash-stats.mozilla.org/report/index/017d90d4-d65a-4d1c-848a-7b1f50210618

https://crash-stats.mozilla.org/report/index/c6e7025b-e89f-422c-a3e9-015580210618

In my case, I'm running FF 89 in safemode for two day without issues, so, I can't guess if it's related to a (previously working) add-on or some other thing. I'm using for years without issues:

• Gesturefy
• Evernote Web Clipper
• Feedly Subscribe Button
• Livemarks
• OneTab
• Tab Session Manager

Does anyone with this issue have installed some of this add-ons (plenty functional in FF pre 89 version)?

I ran FF 89 without issue after it was updated for me yesterday, but have experienced hangs on it today.
https://crash-stats.mozilla.org/report/index/bp-f6447604-48e7-4d15-bbaa-d6a4c0210618

Optional, what distro are you using?
Can you try running the official mozilla build instead of a distro one and see if you see the same hangs?

I was running official FF 89 developer edition (beta) from tarball. There was hangs. Installed add-ons does not affect this.
It hangs on clean profile too. My distro: Xubuntu 18.04.5 LTS
Now I can not reproduce these freezes due to the update to 90 beta (profiles can't run with older versions of FF).

phoenix it looks like you might be having a different problem. You're not using Software WebRender and your crash report shows a different stack. I've filed bug 1717256 to track that issue. If you can describe what you see happen and any steps to reproduce it in that bug that would be great.

If anyone can produce a crash report of a hang with an official build from http://ftp.mozilla.org/pub/firefox/releases/89.0.1/ that would be very helpful.

https://crash-stats.mozilla.org/report/index/550e7584-c0f1-4800-a418-98ebe0210618

(In reply to Optional from comment #35)

https://crash-stats.mozilla.org/report/index/550e7584-c0f1-4800-a418-98ebe0210618

That's from a distro build right?

Ok, have ruled out safe mode, add-ins, bookmarks, profile, and v89.0 showing no difference from v89.0.1.
If eOS AppCentre is now in question, I need an explanation of what exactly is the "official mozilla build." Is it through apt, flatpack, mozilla website, ubuntu repo, or somewhere else? I appreciate the desire to whittle away variables, but this feels like desperation.

I downloaded the mozilla website auto-select version, and I can tell I'm launching that v89.0.1 application because of the setup blankness, but now I'm getting icons mixed up because the install appears to have pointed everything at the same place, somehow. I need to save this check-off right now, before this particular install hangs again.

LILO, I consider eOS appcentre to be "distro build."

Sorry, just considered eOS may not be common jargon for elementary OS.

(In reply to Optional from comment #37)

Ok, have ruled out safe mode, add-ins, bookmarks, profile, and v89.0 showing no difference from v89.0.1.
If eOS AppCentre is now in question, I need an explanation of what exactly is the "official mozilla build." Is it through apt, flatpack, mozilla website, ubuntu repo, or somewhere else? I appreciate the desire to whittle away variables, but this feels like desperation.

The official builds are builds from here: http://ftp.mozilla.org/pub/firefox/releases/89.0.1/linux-x86_64/.
You should be able to just download something like http://ftp.mozilla.org/pub/firefox/releases/89.0.1/linux-x86_64/en-US/firefox-89.0.1.tar.bz2, extract it, and run it.

And yes, if you're getting Firefox from an elementary OS package, that's considered a distro build.

The official builds are builds from here: http://ftp.mozilla.org/pub/firefox/releases/89.0.1/linux-x86_64/.
You should be able to just download something like http://ftp.mozilla.org/pub/firefox/releases/89.0.1/linux-x86_64/en-US/firefox-89.0.1.tar.bz2, extract it, and run it.

And yes, if you're getting Firefox from an elementary OS package, that's considered a distro build.

89.0.1 from tarball, clean profile (only disabled smooth scrolling and enabled restore session), hang after almost 40 minutes of browsing:
https://crash-stats.mozilla.org/report/index/0e02c0c9-f7ac-44a4-a552-3d1e60210619

Perfect. That suggests that this is not related to it being a distro build. Do the steps at bug 1716160 comment 0 reliable reproduce the problem for anyone?

If anyone can produce a crash report for a beta build of FF90 that would be helpful too.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #42)

Perfect. That suggests that this is not related to it being a distro build. Do the steps at bug 1716160 comment 0 reliable reproduce the problem for anyone?

Done. 89.0.1 https://crash-stats.mozilla.org/report/index/4032520a-43d8-408f-b54b-cd08f0210619
Frozen. But not immediately after that steps. After that steps FF worked until i began move map. :)

No problems with windy.com. Neither selecting locations or moving the map.

Valeriy, can you try a 90 beta?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #46)

Valeriy, can you try a 90 beta?

After using windy.com about 5 minutes FF 90.0b9 (64-bit) works fine.

Interestingly, FF 89.0.1 started to freeze almost immediately after loading windy.com without any interaction with it.
Here another crash report: https://crash-stats.mozilla.org/report/index/572aab37-fae2-42af-83ae-510500210619

Varleriy, do you think you could try using mozregression to find out when it was fixed?

What the heck… Another two times i started 89.0.1 and loaded windy.com it works fine.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #48)

Varleriy, do you think you could try using mozregression to find out when it was fixed?

I don't know how to use it. Need to read some tutorial or docs.

There are docs here: https://mozilla.github.io/mozregression/documentation/usage.html
Something like: mozregression --find-fix --bad 89 --good 91 might do it

(In reply to Jeff Muizelaar [:jrmuizel] from comment #51)

There are docs here: https://mozilla.github.io/mozregression/documentation/usage.html
Something like: mozregression --find-fix --bad 89 --good 91 might do it

I ran mozregression --repo mozilla-beta --good 2021-06-01 --bad 2021-05-21 --find-fix
Dates of 89beta16 and 90beta1. Answered "good" and "bad". Got this link:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=67bf1ce890042f5eea2759795e46bef4fa23986c&tochange=a3d6c3cd3b32ec2279fbb96a9cef5a29fd5c112a
List is tooo long.

v89.0.1 mozilla archive:
https://crash-stats.mozilla.org/report/index/13fbbf2e-d010-4265-9270-a3e960210619

(In reply to Valeriy Kryvoshyia from comment #52)

I ran mozregression --repo mozilla-beta --good 2021-06-01 --bad 2021-05-21 --find-fix

You can't run it on mozilla-beta. It has to be on Nightly, because that's where most changes initially land. The command line options like Jeff suggested will do that.

v89.0.1 mozilla archive:
https://crash-stats.mozilla.org/report/index/0f6ea540-9a3b-4813-92f5-5503b0210620

Optional, can you try 90 http://ftp.mozilla.org/pub/firefox/releases/90.0b9/

v89.0.1 mozilla archive:
https://crash-stats.mozilla.org/report/index/31ed1646-c589-4b9e-b642-6f91e0210620

(In reply to Jeff Muizelaar [:jrmuizel] from comment #56)

Optional, can you try 90 http://ftp.mozilla.org/pub/firefox/releases/90.0b9/
Ok, still game. There are a hundred subdirectories in linux-x86_64; what am I supposed to do with that?

Those are just the localizations. You can just use http://ftp.mozilla.org/pub/firefox/releases/90.0b9/linux-x86_64/en-US/ if you don't mind English.

90.0b9 (64-bit) works fine. No freezes since update from 89.0b16 to 90.0b1.

(In reply to Andrew McCreight [:mccr8] from comment #54)

(In reply to Valeriy Kryvoshyia from comment #52)

I ran mozregression --repo mozilla-beta --good 2021-06-01 --bad 2021-05-21 --find-fix

You can't run it on mozilla-beta. It has to be on Nightly, because that's where most changes initially land. The command line options like Jeff suggested will do that.

I still don't understand fully how mozregression actually works. What should i answer on question "Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter)"? I answered "bad" for 89 and "good" for 90. I didn't tested for freezes FF instances launched by mozregression.

If you run mozregression --find-fix --bad 89 --good 91. It will keep download builds, for each build you should test whether you can reproduce the hang. If you do see a hang answer "bad", if you don't answer "good". This will narrow down the actual change that fixed it and we'll be able to back port that fix to 89

It would also be valuable if someone can reproduce the hang while running with rr. i.e. rr [path to official 89.0.1 firefox binary]

I am witnessing something similar since updating to FF89 . When I start Firefox it works fine as usual but after sometime when I switch away to other programs for a while and then return to Firefox, I cannot see the UI window anymore i.e. when I switch back to Firefox the display just keeps showing an image of last window I was on before switching to Firefox and it just gets stuck there. For some reason FF is not able to come back and update the display.
I have tried the nightly FF91 and it still hangs.

What I tried (FF89)

• Remove .mozilla and start fresh with plugins (hangs)
• Start fresh without plugins (hangs)
• Use official build, not the distro build (hangs)

(In reply to kansi13 from comment #64)

I am witnessing something similar since updating to FF89 . When I start Firefox it works fine as usual but after sometime when I switch away to other programs for a while and then return to Firefox, I cannot see the UI window anymore i.e. when I switch back to Firefox the display just keeps showing an image of last window I was on before switching to Firefox and it just gets stuck there. For some reason FF is not able to come back and update the display.
I have tried the nightly FF91 and it still hangs.

That sounds like a different bug. Can you file a new one and post the contents of you about:support. You can link to it from here and I'll make sure it ends up in the right place.

As requested, created a new issue here https://bugzilla.mozilla.org/show_bug.cgi?id=1717347

(In reply to Jeff Muizelaar [:jrmuizel] from comment #62)

If you run mozregression --find-fix --bad 89 --good 91. It will keep download builds, for each build you should test whether you can reproduce the hang. If you do see a hang answer "bad", if you don't answer "good". This will narrow down the actual change that fixed it and we'll be able to back port that fix to 89

With "--good 91" doesn't work showing error:
"0:04.43 ERROR: The url 'https://hg.mozilla.org/mozilla-central/json-pushes?startdate=2021-04-19&tochange=91' contains no pushlog. Maybe use another range ?"

How about mozregression --find-fix --bad 89 --good 2021-06-01?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #68)

How about mozregression --find-fix --bad 89 --good 2021-06-01?

91.0a1 -> good
90.0a1 -> good

2:22.77 INFO: application_version: 90.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
17:14.91 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.

(In reply to Valeriy Kryvoshyia from comment #69)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #68)

How about mozregression --find-fix --bad 89 --good 2021-06-01?

91.0a1 -> good
90.0a1 -> good

2:22.77 INFO: application_version: 90.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
17:14.91 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.

You were not able to reproduce the hang in 2021-04-19 build with version 90.0a1?

Maybe try something like mozregression --find-fix --bad 2021-04-05 --good 2021-06-01?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #59)

…if you don't mind English.

You're allowed to smirk at my not realizing I was looking at a list of localizations.
After a day with v90.0b9 (64-bit), it feels similar to v91.0a1 (2021-06-15) (64-bit), if subjectively less wonky.

I've experienced two "freezes" in this time, slowdowns that I didn't necessarily feel building. In one, I gave up waiting and moused FF to manually relaunch, returning to a decent experience with the same tabs, and the other resurrected 30 < 60s after death in the middle of an advertisement video by slashing through a half-dozen mouse clicks, a surprise when I was just reaching for the crash reporter.

(In reply to rafael.linux.user from comment #72)

Ver 89.0.1 and continues freezing now and then :( I hate to use Chrome but have no choice. If I install a previous Firefox version, it notice me about "to use a new profile", so not way to avoid to use Chrome. Really sad.

What configuration of computer do you use?

Valeriy, were you able to have any success with mozregression? Can you still reproduce the hang on windy.com?

Anyone who can reproduce the problem can you try both of these builds:
A: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2
B: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JwkodM-8R8a12V5RTwInKg/runs/0/artifacts/public/build/target.tar.bz2
and report if you can reproduce the problem in either one?

Since my last comment, beta has winked out twice. Select a page element then poof, no screen or process fragments, just gone. This is a new thing.

(In reply to Optional from comment #76)

Since my last comment, beta has winked out twice. Select a page element then poof, no screen or process fragments, just gone. This is a new thing.

Does anything show up in about:crashes?

(In reply to Valeriy Kryvoshyia from comment #73)

(In reply to rafael.linux.user from comment #72)

Ver 89.0.1 and continues freezing now and then :( I hate to use Chrome but have no choice. If I install a previous Firefox version, it notice me about "to use a new profile", so not way to avoid to use Chrome. Really sad.

What configuration of computer do you use?

opensuse 15.2 (2 distinct PC's and users) plenty of RAM and available space on SSD and HD, with the add-ons for Firefox I wrote in a previous post. In my house Firefox 89 version is working without problems with both, openSUSE 15.2 and 15.3

Important note: As I too wrote previously, both PC's are using an http proxy to access to Internet. And in both PCs, Firefox freezes, not crash.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #74)

Valeriy, were you able to have any success with mozregression? Can you still reproduce the hang on windy.com?

I ran it two times and when almost finished got:
ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.
Maybe i just not reproduced hang sometimes. I will try more time.
Later i found one way to reproduce hang: open windy.com, quickly open 4-5 CPU heavy pages and than begin to move windy.com map.
It freezes almost every time and almost instantly.

Valeriy, before trying mozregression again can you try the two builds from comment 76?

Also, what pages are you using for your CPU heavy pages?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #77)

(In reply to Optional from comment #76)

Since my last comment, beta has winked out twice. Select a page element then poof, no screen or process fragments, just gone. This is a new thing.

Does anything show up in about:crashes?
No new crashes listed since comment #57 entry.
Notable, auto-update incremented b9 to b10 and didn't realize it until now (90.0b10 (64-bit)), so I don't know which source winked out.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #75)

Anyone who can reproduce the problem can you try both of these builds:
A: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2
B: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JwkodM-8R8a12V5RTwInKg/runs/0/artifacts/public/build/target.tar.bz2
and report if you can reproduce the problem in either one?

"A" seems works fine. At least my "windy.com + heavy CPU sites" way doesn't hang this build (posting right now under it after >30 min working without hangs).
I will test "B" a little later.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #80)

Valeriy, before trying mozregression again can you try the two builds from comment 76?

Pages from reddit.com (much JS). I have slow laptop, so yes, they are CPU heavy for my Intel Pentium Dual CPU T2370 1.73GHz (plus 2GB RAM) :)
In general, it seems to me that this bug appears only on slow computers. Only little part of FF users experience this hangs.

Sorry for reply to wrong post.(In reply to Jeff Muizelaar [:jrmuizel] from comment #81)

Also, what pages are you using for your CPU heavy pages?

Pages from reddit.com (much JS). I have slow laptop, so yes, they are CPU heavy for my Intel Pentium Dual CPU T2370 1.73GHz (plus 2GB RAM) :)
In general, it seems to me that this bug appears only on slow computers. Only little part of FF users experience this hangs.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #80)

Valeriy, before trying mozregression again can you try the two builds from comment 76?

"B" seemed working fine at first. But eventually froze when i tried to open wikipedia.org from new page.

Crash report for "B":
https://crash-stats.mozilla.org/report/index/cdc50c87-6c7e-41c0-b859-d7c010210621

Valeriy, can you try these as well:
C: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OOkKaJ1DSByl82GFXRXGVQ/runs/0/artifacts/public/build/target.tar.bz2
D: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2

They may crash/exit instead of freezing but please report what you see.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #88)

Valeriy, can you try these as well:
C: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OOkKaJ1DSByl82GFXRXGVQ/runs/0/artifacts/public/build/target.tar.bz2
D: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2

They may crash/exit instead of freezing but please report what you see.

"C" at first worked fine about an hour (windy.com doesn't freeze). But when i have opened youtube video and another site FF crashed:
https://crash-stats.mozilla.org/report/index/df156b4c-56a1-4cb6-b3fd-e3d570210622

I sent the wrong URL for D.
It should be https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SUqaG7CGQeKUR43KtwDliw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Jeff Muizelaar [:jrmuizel] from comment #90)

I sent the wrong URL for D.
It should be https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SUqaG7CGQeKUR43KtwDliw/runs/0/artifacts/public/build/target.tar.bz2

Just wanted to write that "D" works without freezing and crashes. :D Seems that wrong "D" build works fine.
I will try corrected link.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #90)

I sent the wrong URL for D.
It should be https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SUqaG7CGQeKUR43KtwDliw/runs/0/artifacts/public/build/target.tar.bz2

This build has crashed while loading page and i was typing address in address bar.
https://crash-stats.mozilla.org/report/index/6cce2964-a3df-47a5-b5fd-e09c60210622

and one more for the night:
E: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fm_HC5lyTK2Vp9KWHwxH0Q/runs/0/artifacts/public/build/target.tar.bz2

"E" seems work fine without freezes and crashes. Browsed different sites, windy.com + "CPU highload", viewing youtube video, etc.
That is, the actions performed could potentially lead to a freeze, and nothing happened (except for heavy swapping caused by 2 GB of RAM + several applications in the background).
I am trying to test for about 40-60 min. May need more time for testing to be sure.

and one more for the night
It's morning here. 6:30 am :)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #93)

and one more for the night:
E: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fm_HC5lyTK2Vp9KWHwxH0Q/runs/0/artifacts/public/build/target.tar.bz2

One more thing. "Home" button disappeared from toolbar.

Valeriy, are you able to try running the official 89.0.1 build with rr to see if you can still see the hang?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #96)

Valeriy, are you able to try running the official 89.0.1 build with rr to see if you can still see the hang?

My laptop have too old CPU:
"rr is incompatible with ptrace hardening, and currently only supports
Intel CPUs with Nehalem or later microarchitectures."

Not typical to comment when there's nothing new to report, but after a couple of days I can claim it's a new thing I haven't crashed since v90 b10/b11.

I've relaunched only twice because FF had slowed to a crawl, preferable to hanging and crashing without repeatability. For future reference, I hope those with know-how can point at whatever was attempted in 89 and conclude it was a bad idea, even if the pointer swings toward the OS or some other culprit, but I also maintain hope that release 90 doesn't bog down so much.

I use developer edition, i. e. 90.0 (now beta 11), almost whole day. It has no hangs or any critical bug. There is some glitch when drawing the interface.
Also i have downoladed 89.0.2 tarball from mozilla.org. It seems that hangs was fixed and this FF branch works stable. Or not? Is there any information about fix? I saw in release notes of 89.0.2:
«Fix occasional hangs with Software WebRender on Linux (bug 1708224)»

Yes, 89.0.2 should fix the hangs people are seeing here. If anyone still see hangs on 89.0.2 please let me know.

No hangs, yet. Thought I'd jump on this after reading the details, but after futzing for an hour, v89.0.2 doesn't display hover arrows for window resize.

Cursor arrows don't appear anywhere hovering on the perimeter, but they do appear and function if mouse-down on the expected target. I use the word target because it's kinda hit and miss, clicking where I think the arrow would normally pop up on hover but not always hitting the bullseye; best to aim for the window shadow with some room for error. After mouse-down, arrow cursor appears and window size drag works as expected. Min/max toggle and tab bar window drag work as expected, and new launch window size is taken from previous quit--not window position.

Was this a design decision? Is it related to the LInux bug fix?

There should be no difference in hover arrows for window resize. Can you double check that you see a difference between 89.0.1 and 89.0.2?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #102)

There should be no difference in hover arrows for window resize. Can you double check that you see a difference between 89.0.1 and 89.0.2?

Definitely different. Not cocky; just double-checked side by side and hover arrow from v89.0.1 has disappeared from v89.0.2.

That's super interesting. What window manager are you using?

Also, what behaviour do you see in this build?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2

(In reply to Jeff Muizelaar [:jrmuizel] from comment #104)

That's super interesting. What window manager are you using?

Over my head, but:

skyhook@backhoe:~$ wmctrl -m
Name: Mutter(Gala)
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A
skyhook@backhoe:~$ printf 'Desktop: %s\nSession: %s\n' "$XDG_CURRENT_DESKTOP" "$GDMSESSION"
Desktop: Pantheon
Session: pantheon

Have to get back to you on that build link.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #105)

Also, what behaviour do you see in this build?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2

Oh, that was easy. I'm getting faster at this:
Assuming you intended me to install "Nightly v89.0.2 (64-bit)," the hover arrows are there and work as expected.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #105)

Also, what behaviour do you see in this build?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A5LLyBrmR-ynlYUXXIH8Yw/runs/0/artifacts/public/build/target.tar.bz2

My dysfunctional v89.0.2 (64-bit) was installed from Mozilla Flatpak, found through Flathub in the eOS AppCenter.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #100)

Yes, 89.0.2 should fix the hangs people are seeing here. If anyone still see hangs on 89.0.2 please let me know.

I had the issue in 89.0.1 in a lot of websites, so i revert to 89.0.0 and the issue only occur in google maps Zooming. I had updated to 89.0.2 and the problem still occur in google maps zooming.

Tested in safe mode and the problem is gone.
Removed all addons to check it, but the problem still happen.
Create a new profile, the problem still occur.

Firefox 89.0.2 Linux Slackware64-Current

Thiagomelobr, can you attach your about:support from 89.0.2?

thiagomelobr, you're not using software webrender so your problem looks like a different one than this one. Can you file a new issue?

In that sprit of that comment(In reply to Jeff Muizelaar [:jrmuizel] from comment #113)

thiagomelobr, you're not using software webrender so your problem looks like a different one than this one. Can you file a new issue?

Jeff, in the spirit of that comment, and considering that my lastest v89.0.2 update (maybe on the weekend, I forget) seems to utilize window resize arrows as expected like your v89.0.2 Nightly, should this bug report be closed with the webrender/NaN fix? Are we at a conclusion, before others dog-pile onto my vague title with unrelated issues? You didn't hint at why your v89.0.2 Nightly link behaved different from the AppCentre v89.0.2 flatpack, but if that's water under the bridge I'm okay with it.

I guess I'm asking if v89.0.2 is the most resilient things will get, for now.

Don't understand why I had an AppCentre v89.0.2 update when it's different from v89.0.2 flatpack (not v89.0.2 Nightly), but AppCentre offerred it up so I thought the more the merrier? Still wish this wasn't dogging it worse than pre-v89, but it works. I'd like to delete the variety of FF versions I currently have installed and focus on fixing preferences for a single install that I'll continue with.

I am still experiencing some intermittent freezing after upgrading to v89.0.2, but not nearly as much as with v89.0.0.
Attached is my about:support from v89.0.2

(In reply to Jeff Muizelaar [:jrmuizel] from comment #110)

Thiagomelobr, can you attach your about:support from 89.0.2?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #113)

thiagomelobr, you're not using software webrender so your problem looks like a different one than this one. Can you file a new issue?

done. https://bugzilla.mozilla.org/show_bug.cgi?id=1718847

I'm still experiencing this issue on Firefox 90.0.2.

Firefox is freezing roughly every 20-40 minutes and doesn't respond to anything short of a SIGTERM to get it to terminate.

Here's a link to my about:support
https://gist.github.com/zealws/8bd97f620c853d8c62dbaa04cde0591f

(In reply to zeal from comment #118)

I'm still experiencing this issue on Firefox 90.0.2.
Firefox is freezing roughly every 20-40 minutes and doesn't respond to anything short of a SIGTERM to get it to terminate.

I've added nothing new to this conversation because my FF v90.0.2 does the same thing, not a crash but a slow death, and it has nothing to do with my original bug description which was cured from a crash, not just a hang. v90.0.2 doesn't crash.

If I don't relaunch a deadly slowdown when first noticed, like keyboard input charging ahead of what's appearing on screen, I risk a reboot instead of relaunch because FF never comes back the way it should. Everything works since FF v90.X, including some unexpected video playback improvement, and FF instructions state to relaunch for slowdowns. The sites for this behaviour are commonly video playback, games, and news, all ad-rotation-heavy; an excuse but livable for me.

What I find most interesting is that a relaunch only helps about half the episodes and a reboot is required, indicating to me that the engine is the problem, essentially acknowledged by Mozilla by instructions to relaunch as if Gecko isn't going to change so get over it. Closing tabs achieves nothing, assuming my mouse is still usable, which I thought would indicator short RAM. Restricting open tab count also seems to have little effect, as it's one deadly tab causing the slowdown.

Yes, relaunch sucks and reminds me of Netscape's worst days. If I compare Chrome on a clean boot, Chrome is actually slower at first, but while FF slows over time until I can't take it anymore, Chrome seems to maintain a slower while even pace forever. At least, I've never crashed or hung Chrome this way, or seen it suffer some other seizure.

For the record, my eOS Epiphany sometimes can't load some sites at all, so nothing to see there. I'm tempted to try Opera again as WebKit spawn, but I grew tired of messing with this issue once v90.X gave me a workable solution. Because pre-v89 was worry free, it gives me pause to measure what was gained since.

(In reply to zeal from comment #118)

I'm still experiencing this issue on Firefox 90.0.2.

Firefox is freezing roughly every 20-40 minutes and doesn't respond to anything short of a SIGTERM to get it to terminate.

The next time you hit this issue could you kill Firefox with SIGABRT instead? That will generate a crash report that you can submit, it should shed some light on the cause especially if the main process is completely stuck (i.e. the UI is non-responsive).

I did a system upgrade two days ago and the freezing got a lot less frequent. One freeze since then.

The next time you hit this issue could you kill Firefox with SIGABRT instead? That will generate a crash report that you can submit, it should shed some light on the cause especially if the main process is completely stuck (i.e. the UI is non-responsive).

I did this. I didn't see any way to download the crash report, or view it, but I did submit it for Mozilla to review, and placed a URL to this bug in the comments of the report.
Hopefully you can look it up by searching for this URL in the comments?

Or if there's a different way to get the bug report, I can do that next time it freezes?

zeal, can you go to about:crashes and post a link to the crash report to this bug?

I did a system upgrade two days ago and the freezing got a lot less frequent. One freeze since then.

I spoke too soon, it's frozen 4 or 5 times since then. :(

zeal, can you go to about:crashes and post a link to the crash report to this bug?

Ooh, yeah!

https://crash-stats.mozilla.org/report/index/cf0a3db0-dddf-452f-9de2-50f1e0210810

zeal, it looks like a separate problem so I've filed bug 1725009.

Optional, zeal, could you post the outputs of xrandr --listproviders here? It it contains name:Intel, then you're likely to run into bug 1710400.

(In reply to Robert Mader [:rmader] from comment #125)

Optional, zeal, could you post the outputs of xrandr --listproviders here? It it contains name:Intel, then you're likely to run into bug 1710400.

Sorry for the delay; thought I was out of this fight:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x246 cap: 0x1, Source Output crtcs: 2 outputs: 4 associated providers: 0 name:NVIDIA-0

Useful? Not Intel so unrelated?

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Pretty sure this has been fixed by switching to EGL (and using SW everywhere else).