It started for me in the past 2/3 days (OS X, Nightly): Firefox UI becomes completely unresponsive, in the Activity Monitor I see "Nighty Web Content" spiking up to 70-100%. Example: while writing this comment the UI stopped at least 3 times, cursor stops blinking for 4/5 seconds, and then it starts working again. At first I thought it was a problem with text areas, but it happens on websites like YouTube. As it is, the browser is basically unusable. The only add-on installed is LastPass 4.1.29a

I'm currently trying with all add-ons disabled, and I'm not seeing any block. Waiting a bit more before updating the bug subject.

In safe-mode everything works normally. Restarted in normal mode and disabled LastPass, I'm still not seeing any hang in the UI.

may be related to bug 1096103?

I don't think so, I've been using LastPass 4 for several months on Nightly without particular issues. Now I've re-enabled it again, but weirdly enough I'm not experience those hangs yet (I've seen them on two different macs over the weekend).

This needs triage. --> Untriaged (Please do not file bugs in Fx::General unless you are sure that the issue is one with Firefox's UI that does not fit one of the more specific components. If you're using a bugzilla page/form where this product/component is automatically prefilled or suggested, please let me know so we can fix it.) To move this bug forward, I expect a profile from the gecko profiler or the builtin (browser toolbox) profiler would be helpful in order to figure out *what* is slow, exactly.

(In reply to :Gijs Kruitbosch from comment #5) > If you're using a bugzilla page/form where this > product/component is automatically prefilled or suggested, please let me > know so we can fix it.) Uh, sorry, that's all on me. I had no idea I was supposed to start from Untriaged. I'm still trying to narrow down the issue, after Firefox started behaving normally. Might end up as WORKSFORME if it doesn't start hanging up again.

I've seen something similar to this, but I don't use LastPass (but I have a bunch of other add-ons, including 1Password). For me, it started a few weeks ago on Nightly. I'll check the ActivityMonitor next time it happens and see if it sees the Web Content Process CPU spiking....

After restarting in safe-mode, Firefox has been behaving normally for me (currently on 2016-09-13). Let's remove LastPass from the subject at this point.

It seems to happen less frequently, but I've got a couple of "cursor stuck" moments, hopefully I managed to get them in this profile https://cleopatra.io/#report=486784106f2625ef193838c5b89770be7aa81cbf

(In reply to Francesco Lodolo [:flod] from comment #9) > It seems to happen less frequently, but I've got a couple of "cursor stuck" > moments, hopefully I managed to get them in this profile > https://cleopatra.io/#report=486784106f2625ef193838c5b89770be7aa81cbf That profile shows that there's a big cycle-collection run (at least 11s!) which is blocking your content process. This smells like a memory leak. When you get into this state, can you post an about:memory report?

I've been continuing to see similar stalls, though with a bunch of addons installed, and, like Francisco's case, Nightly Web Content process is chewing CPU when it happens. I haven't yet had a chance to poke at it with Cleopatra....

I'm clearing the NI for now, but the bug remains on my radar. I have an open tab with about:memory to save a report in case it happens, but I can't reproduce it reliably anymore.

From comment #7, this doesn't appear to be LastPass only. Certainly appears to be add-ons based.

I too have started to notice this, at first I thought it might have been something in the background chewing away the HDD, but it turns out its Firefox itself that is doing it. This started with v51 or some minor update on v50 of Nightly, can't be sure. I can't, yet, make the bug trigger reliably (I don't even know what causes the unresponsiveness) but it does seem to trigger more often on pages that have some sort of "large" media on them, like youtube, imgur or google images. "Simpler" pages, like a google search result page, don't seem to cause the issue, so this might indeed be the result of long garbage collection. Average memory usage, relative to previous version, doesn't seem to be that much different, if anything it seems to be lower now. Even after the unresponsiveness ends the memory usage (commit) doesn't seem to change. I seem to recall a similar issue (same symptoms) around v3 or 4, fixing the issue was as simple as vacuum the various DBs (cookies, bookmarks, etc.). I used the Places Maintenance extension for that, doesn't seem to help with this issue though, since the issue can present itself on a clean profile too.

mconley: here's a memory report from several minutes after I saw this happening. Does that help?

Forgot to mention that this report is from 51.0a2 (2016-09-26) (64-bit) on OS X 10.11.6

Another action for sufferers to help us gather information - please set javascript.options.mem.log to true, and when you experience this, open the Browser Console, and paste the contents into an attachment for this bug. Until then, I guess I'll needinfo mccr8. Hey mccr8, is any of the information in here (profile in comment 9, memory report in comment 15) actionable? At least in the profile, it looks like we've got an extremely long CC going on (>11s!) If not, is there anything else that sufferers can do to gather us more actionable information?

This sounds a lot like bug 1301301, which was fixed in the 9-27 Nightly. Let me know if you still see this issue in newer Nightlies.

based on comment 18 - did you get resolved after that fix landed?

(In reply to :shell escalante from comment #19) > based on comment 18 - did you get resolved after that fix landed? I haven't seen this behavior in a while, but there are also other people reporting the issue in the bug.

I haven't seen the problem since I started using a nightly with the fix.