Closed Bug 1065463 Opened 10 years ago Closed 9 years ago

Firefox sometimes freezes for several seconds when closing tab with middle-click

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
33 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1067470

People

(Reporter: hannu.nyman, Unassigned)

Details

Firefox sometimes freezes for a few seconds when deleting a tab with mouse middle-click to the tab title. Tab does not disappear and changing tab is also impossible, as Firefox is frozen. After a few seconds Firefox wakes and finally deletes the tab. But it also performs other mouse actions as if the deletion would have been done immediately: e.g. if I have re-clicked the tab trying to delete it again, Firefox also deletes the next tab (like it would have been on the place of the deleted tab when I made the second click). It almost sounds like Firefox pauses the screen updates, but performs the actions in background.

STR:
Open several tabs.
Use mouse middle-click to close one of early tabs.
Sometimes Firefox freezes.

This has happened since middle August, maybe once per every 2-3 days.

Windows 7 x64, Nvidia display card.

I first noticed this with Aurora 33 and now it continues with Aurora 34.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140910004000 CSet: 0890010015a2

(note: Bug 1019615 may be somehow related. It sounds a bit different, but has some similar aspects.)
Version: unspecified → 33 Branch
Could you install the gecko profiler add-on (see https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler ) and get a profile report after such a hang happens, and pass us the cleopatra URL? That'd be super helpful, especially considering it happens so infrequently.
Component: Tabbed Browser → Untriaged
Flags: needinfo?(hannu.nyman)
(note to self: might be related to bug 933733 / bug 896896, although the timeframe is somewhat off there (landed in 32))
Thanks for the debug advice. I have installed the profiler and will upload & post the profile reports.

Regarding the timeframe thoughts in comment 2, this may have been surfaced during Aurora 32 phase, but it may have gone unnoticed by me as I was on vacation and away from my PC most of that time.
Flags: needinfo?(hannu.nyman)
Passing the cleopatra URL does not seem to be easy, as the profile size seems to exceed the allowed size. After selecting "share" and waiting for up load and then server-side compression, I get an error:
"Error 0 occurred uploading your file. The profile that you are trying to upload is more then the 9 MBs storage maximum. For more information see how to host your profile."

I uploaded the profile to Dropbox. See
https://www.dropbox.com/sh/uf8imhurje9g3sh/AAAjaENTTzLpXkHVxdsnXY1Na?dl=0
Thank you! I will have a look on Monday. :-)
Flags: needinfo?(gijskruitbosch+bugs)
We seem to just be stuck in NtWaitForMultipleObjects all the time, which looks suspiciously like bug 937306... That means that things should improve in today's copy of Aurora. Hannu, can you let us know if it does? And Bas, can you doublecheck that my suspicions are valid? :-)
Flags: needinfo?(hannu.nyman)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(bas)
(In reply to :Gijs Kruitbosch from comment #6)
> We seem to just be stuck in NtWaitForMultipleObjects all the time, which
> looks suspiciously like bug 937306... That means that things should improve
> in today's copy of Aurora. Hannu, can you let us know if it does? And Bas,
> can you doublecheck that my suspicions are valid? :-)

Hrm, I can confirm when I keep middle clicking Firefox stops being sensitive to Double-Click, but it doesn't actually freeze, i.e. other interactions just work. NtWaitForMultipleObjects doesn't mean that much, really, that just means we're 'waiting for stuff to do', which could mean anything. So I can't really tell you the answer to that :).
Flags: needinfo?(bas)
Sadly, it is something else and the bug is still there.

I had about 5 tabs open when Firefox froze deleting one of them. That is just a few seconds before the end of this analysis. After the freezing there is just a test click to change the tab (nothing happened), and then waiting for the tab deletion and the tab change to materialize, finally one more tab change and then to Cleopatra.

Direct link to profile in Dropbox:
https://www.dropbox.com/s/1pwlsgu1c6tkfok/A9EN44RN?dl=0

Today's Aurora: 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140917004003 CSet: e20869e87e23
Flags: needinfo?(hannu.nyman)
Have you any specific hints on what kind of actions I should try to debug?

I have just tried to change tabs and then waited, but I haven't really tested if menus works during the "freeze", or if painting text with mouse on the visible page is possible etc.
What would be the most useful actions to test during the next "freeze"?
(apologies for the silence, I was away for a while and this got buried under stuff)

Unfortunately I'm not sure how best to debug this further... njn or bas, can you help investigate this further?
Flags: needinfo?(n.nethercote)
Flags: needinfo?(bas)
I don't have anything to add here. It doesn't look like something involving my areas of expertise, sorry.
Flags: needinfo?(n.nethercote)
This issue happens for me too. Sometimes (2-5 times per day) Firefox 33 freezes for 3-10 seconds when I try close or switch tabs. Never happened before version 33.
Following the advice on mozillazine to disable OMTC seems to workaround bug. I have yet to experience a single hang since disabling it.
(In reply to anonbugreport from comment #15)
> Following the advice on mozillazine to disable OMTC seems to workaround bug.
> I have yet to experience a single hang since disabling it.

As OMTC is the major feature introduced in FF33, it's probably the cause of this issue.
Could you type about:support and paste the "graphics" section.
Redirecting needinfo to Milan based on comment #15 / comment #16.
Flags: needinfo?(bas) → needinfo?(milan)
> paste the "graphics" section.
Didn't try with disabled OMTC yet, but it happens for me with both Intel(R) HD Graphics 4600 at work and  NVidia 8800GT at home
http://pastebin.com/jYcfkDEu
I am currently (Aurora 35) seeing the freeze more often than earlier but freezes are maybe shorter. 

Right-clicking on the page will also cause Firefox to wake up, so I believe that Bug 1019615 is a duplicate of this.

Here is my about:support Graphics section:
http://pastebin.com/Nwe2J5kt

I will try disabling OMTC.
The other thing to try is disabling D2D by setting gfx.direct2d.disabled to true (without disabling OMTC) and let us know what that does.

What would really help is installing and running the latest Nightly (https://nightly.mozilla.org/), without any changes to preferences, and tell us if that makes the problem go away.
Flags: needinfo?(milan)
Here's my graphics section:
http://pastebin.com/b1zCNrg2

Going to try gfx.direct2d.disabled now.
(In reply to Milan Sreckovic [:milan] from comment #20)
> The other thing to try is disabling D2D by setting gfx.direct2d.disabled to
> true (without disabling OMTC) and let us know what that does.
> 
> What would really help is installing and running the latest Nightly
> (https://nightly.mozilla.org/), without any changes to preferences, and tell
> us if that makes the problem go away.

Bug still occurs with direct2d disabled and OMTC enabled.
I'm having this exact issue in Firefox 33.
> Right-clicking on the page will also cause Firefox to wake up
true
Updating to 33.1 fixed it for me.
Nevermind, it still happens.
running 33.1.1 and the momentary freeze ups are happening more frequently than recent prior versions prompting me to file this (my first) Firefox bugzilla comment.   Win7 Pro 64bit.
The problem is still there in the new Aurora / Developer Edition 36.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141205080111 CSet: 828a534b9653

I tested a while ago with OMTC disabled, and that seemed to remove the problem.
Freezes still occurs in Firefox 34.
Freezes still occurs in Firefox 34.0.5
I have the same freezes sometimes with removing or switching to a tab.  It started with version 33.0 and continues now with 34.0.

Win 7 sp1 x64 fully patched.
NVidia NVS 4200m version 341.05 (latest driver as of this posting).

When it happens while switching, the header for the tab switching to paints/draws fine (it's now the current tab), but the page content from the previous tab is still displayed (only the header switched).

It's very annoying.
You can right click to wake up Firefox. I have this issue too, sometimes, but it's almost impossible to reproduce it. Probably due to OMTC.
(In reply to Loic from comment #32)
> You can right click to wake up Firefox. I have this issue too, sometimes,
> but it's almost impossible to reproduce it. Probably due to OMTC.

You're running Nightly, right?

comment #28 says disabling OMTC does help, comment #22 that disabling direct2d doesn't. I'm confirming this because so many people seem to be running into it, and moving to graphics considering that disabling OMTC fixes it.

Milan, what can we do to investigate/prioritize this further?
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
Flags: needinfo?(milan)
Product: Firefox → Core
Aaron, given your work on bug 937306, any insights?  I know we're currently tracking in graphics because of OMTC, but OMTC changes the timing of things, introduces more threads, and it may very well be just uncovering an underlying issue elsewhere.
Flags: needinfo?(milan) → needinfo?(aklotz)
According to feedback from the SUMO folks, every time that they've encountered this issue there has been malware involved. I don't want to incite panic amongst our helpful reporters, but it would be great if everybody could scan for malware and report back as to whether anything improved.

Obviously I want to help in any way that I can, but I think we should eliminate known causes first.
Flags: needinfo?(aklotz)
Well, I have up-to-date antivirus & firewall from F-Secure and no malware has surfaced for ages. Just did a scan and no problems were found.

And turning off OMTC disables then the well-hidden malware, right? Is that how the logic goes?
As disabling OMTC cures the problem...

I find that a rather strange approach vector to this bug.
(In reply to hannu.nyman from comment #36)
> And turning off OMTC disables then the well-hidden malware, right? Is that
> how the logic goes?
> As disabling OMTC cures the problem...

What happens is that malware can spin up their own threads inside our process, create windows (visible or hidden), and create parent-child relationships between its windows and Firefox windows. Due to the way that Windows works, if the malware has done this, and then hangs or does something that can be slow (like disk I/O), it can cause other threads in Firefox to hang as well.

OMTC doesn't toggle the malware, but it amplifies the effect of any "bad" stuff that malware is doing.
I'm having this exact issue since Firefox 33, tabs may hang for a few seconds when switching or closing. It doesn't happen very often, maybe once or twice a day. Sometimes it doesn't happen for several days, so it's very difficult to reproduce.

Disabling OMTC cures the problem. As OMTC has been activated in Firefox 33, it makes sense. A new profile doesn't help. Right-clicking wakes up the tab.

I don't have any malware, never had. I regularly check my pc with malwarebytes and kaspersky : I've never found ANY problem. Every other piece of software in my pc works flawlessly. My other browsers do not have this issue, only Firefox.
Clearly not a malware issue, this bug came with FF33.
(In reply to Loic from comment #39)
> this bug came with FF33.

I'm aware of that; many of the problems we've seen in related bugs have been due to bad interactions between malware and OMTC.

Since many users on this bug are confident that they are malware free, I'm going to proceed assuming that it is not the issue in this case. I wanted to rule out the obvious first.
I reported Bug 1105891, which appears to be similar to what is being described in this bug.  See Bug 1105891 comment 1 for a profile.

Adapter Description	NVIDIA GeForce GTX 660
Adapter Drivers	nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM	2048
Device ID	0x11c0
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16492)
Driver Date	11-12-2014
Driver Version	9.18.13.4475
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	30693842
Vendor ID	0x10de
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 660 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
If anybody who can reproduce this regularly is interested in trying the Gecko Profiler, it could be helpful. Please see the following URL:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
It seems only Nvidia cards are affected. Am I wrong?
(In reply to Loic from comment #44)
> It seems only Nvidia cards are affected. Am I wrong?

yes :) 
i have a AMD system, on which i can intermittently repro.

see the dupe bug 1019615
(In reply to Loic from comment #44)
> It seems only Nvidia cards are affected. Am I wrong?

I think the issue described here may have happened to me yesterday on a computer with Intel(R) HD Graphics 3000. I had like 20 tabs open all e10s all eBay and with the exception of my yahoo mail tab I closed all of them one at a time and for one of the tabs there was a freeze for several seconds. I don't have a way to reproduce but I tried.

gecko.buildID = 20141219030202
gecko.mstone = 37.0a1
1427b365cd39

I reported bug #1099497 which may be related with a hang on tab open, but to workaround that I kill plugin-container.
(In reply to Loic from comment #44)
> It seems only Nvidia cards are affected. Am I wrong?

I have an AMD card. See comment #21 for details.

Also Malwarebytes and Avast scans detected nothing.
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #43)
> If anybody who can reproduce this regularly is interested in trying the
> Gecko Profiler, it could be helpful. 
The profiles get easily so large that Mozilla server does not accept them :-(

I have again uploaded one profile from a few minutes ago to the same Dropbox folder where my two previously uploaded profiles from September are:
https://www.dropbox.com/sh/uf8imhurje9g3sh/AAAjaENTTzLpXkHVxdsnXY1Na?dl=0
Direct link to the new profile:
https://www.dropbox.com/s/rgomrh8yuc9c6gc/6Dxntal6?dl=0

At the end of the profile, there is about 15-17 second freeze after I tried to close a tab with middle-click. I patiently waited and counted seconds in my head, and after about 15 seconds Firefox finally refreshed the screen. I pushed profiler's Analyse button immediately afterward, so the freeze is in the end section of the profile (at approx 2.760.000-2.787.000ms).

The same profile contains also a previous freeze around 2.440.000 ms.

Cleopatra shows that most of the time has been spent with NtWaitForMultipleObjects, just like discussed in comment 6. Cleopatra also shows in the GeckoMain section several "garbage collection" items, a few references to Bug 720575 and also "Main thread IO!" roughly at the spot where I estimate that I have middle-clicked.


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141222004004 CSet: f414dda8b288
Re-needinfo'ing per comment #48.
Flags: needinfo?(aklotz)
Hello guys!

I thing to have the same bug at my firefox 34 - freezing for some seconds after middle click a link to open in a new tab. It seems that it is gone, if deactivating the WebDeveloper App - maybe this could be a hint for finding the problem!

LG Klaus
Hey everyone,

So while closing a tab in FF 35 I got the normal lock problem but for some reason this time I also got the error: chrome://browser/content/tabbrowser.xml:2077.

After looking at that line on tabbrowser.xml:

              if (closeWindow &&
                  aCloseWindowFastpath &&
                  this._removingTabs.length == 0) {
                // This call actually closes the window, unless the user
                // cancels the operation.  We are finished here in both cases.
                this._windowIsClosing = window.closeWindow(true, window.warnAboutClosingWindow);
                return null;
              }
Could aCloseWindowFastpath be the problem?

Scott
(In reply to scottstown from comment #51)
> Hey everyone,
> 
> So while closing a tab in FF 35 I got the normal lock problem but for some
> reason this time I also got the error:
> chrome://browser/content/tabbrowser.xml:2077.

What error? You omitted the error message...

> 
> After looking at that line on tabbrowser.xml:
> 
>               if (closeWindow &&
>                   aCloseWindowFastpath &&
>                   this._removingTabs.length == 0) {
>                 // This call actually closes the window, unless the user
>                 // cancels the operation.  We are finished here in both
> cases.
>                 this._windowIsClosing = window.closeWindow(true,
> window.warnAboutClosingWindow);
>                 return null;
>               }
> Could aCloseWindowFastpath be the problem?


Unlikely, as this by itself wouldn't cause an actual freeze. Also, this code path only gets taken if the toplevel browser window is being closed, which I'm assuming wasn't the case because you said "closing a tab", not "closing a window"...
Flags: needinfo?(scottstown)
Firefox can freeze  even if you try to open some link with middle click (probably with left click too, but I don't use it) from combobox of awesome bar.
Definitely *not* a malware issue.

I had this same issue on a clean Windows 7 SP1 installation with a clean FF 34.0.5 installation. It had OMTC enabled out of the box and exhibited this problem, but because of Bug 1085673, I had to turn off OMTC anyway, so I hadn't thought to look for bug reports for this issue until I encountered the problem on a different machine.
I may have seen a variant of this bug yesterday with new Aurora 37 when I experienced a freeze with a twist:
I had several tabs open. One of them was a Github commit log page: https://github.com/openwrt/packages/commits/master . When I was on the previous tab and middle-clicked to close it, the tab did not close but froze instead. However, the user icons from that next Github page got quickly painted over the frozen "closed tab", while all other visible content was still from the "closed tab". After a freeze of maybe 2 seconds the remaining of the page refreshed to show Github content. It looked like selected content (or selected refresh methods) got painted on timely fashion, but all other components got pushed to the waiting queue.

I am not 100% sure if this is about the same issue, but it seems possible and might hopefully offer clues for solving this annoying problem. (In any case it looked very strange that the icons got painted over the previous content.)
I just want to confirm that this issue is still happening in 35.0.1 today.
A thread on Reddit has suggested setting layers.offmainthreadcomposition.enabled to false in about:config to resolve this and several people are reporting that this seems to fix it.
(In reply to Pragmatic Software from comment #59)
> A thread on Reddit has suggested setting
> layers.offmainthreadcomposition.enabled to false in about:config to resolve
> this and several people are reporting that this seems to fix it.

Changing my layers.offmainthreadcomposition.enabled value to false causes my Firefox to consistently crash on startup. Restarting my PC didn't fix it.
(In reply to chihuahuasare2cute from comment #60)
> (In reply to Pragmatic Software from comment #59)
> > A thread on Reddit has suggested setting
> > layers.offmainthreadcomposition.enabled to false in about:config to resolve
> > this and several people are reporting that this seems to fix it.
> 
> Changing my layers.offmainthreadcomposition.enabled value to false causes my
> Firefox to consistently crash on startup. Restarting my PC didn't fix it.

Did you open a bug about this issue? Do you have a cresh report to submit in about:crahes?
Flags: needinfo?(scottstown)
Flags: needinfo?(aklotz)
(In reply to chihuahuasare2cute from comment #60)
> (In reply to Pragmatic Software from comment #59)
> > A thread on Reddit has suggested setting
> > layers.offmainthreadcomposition.enabled to false in about:config to resolve
> > this and several people are reporting that this seems to fix it.
> 
> Changing my layers.offmainthreadcomposition.enabled value to false causes my
> Firefox to consistently crash on startup. Restarting my PC didn't fix it.

Perhaps bug 1036742?
Hi, I've been following this thread for a while and this freezing/lagging issue is now becoming so bad, that thought I'd add a comment, just in case it helps.

I had malware affecting all my browsers (FF, chrome, opera, IE) back in november, which I managed to clear with Malwarebytes. All my other browsers have been working fine since, but this annoying freeze/lag issue has persisted in FF, and seems to be getting worse.

Out of desperation, I ran four other malware detection software (SuperAntispyware, Microsoft Safety Scanner, Anti-Rootkit Utility, AdwCleaner). Nada.

Tried changing my layers.offmainthreadcomposition.enabled value to false. This makes the browser unusable, crashes immediately. (tried a few times, each time had to refresh the browser).

I now use chrome and opera for a lot of my browsing as FF is just too laggy, at times freezing completely for over ten seconds or so, and it seems concurrent. Painful.
further to my comment above

typical situation:

switching from tab 1 to tab 2:
tab 2 does not 'open' on the screen, but slowly 'pastes' over tab 1 which is still visible on the screen. 
Interestingly, the images and ad placements seem to appear first, followed by the text on the page. It usually takes several, if not more than ten seconds, for tab 2 to be fully displayed on the screen.

The way I've been able to speed things up a bit: click on tab 2, witness lagging, quickly switch back to tab 1 (which opens without lag) and immediately back to tab 2. Now tab 2 opens without lag.
(In reply to aa from comment #64)
> further to my comment above
> 
> typical situation:
> 
> switching from tab 1 to tab 2:
> tab 2 does not 'open' on the screen, but slowly 'pastes' over tab 1 which is
> still visible on the screen. 
> Interestingly, the images and ad placements seem to appear first, followed
> by the text on the page. It usually takes several, if not more than ten
> seconds, for tab 2 to be fully displayed on the screen.
> 
> The way I've been able to speed things up a bit: click on tab 2, witness
> lagging, quickly switch back to tab 1 (which opens without lag) and
> immediately back to tab 2. Now tab 2 opens without lag.

Do you have any addons installed? You should try testing with those disabled to see if they are the cause.
In addition, after a malware infection, it's better to reset your current profile to restart from scratch with a new profile and only your private data: https://support.mozilla.org/en-US/kb/reset-firefox-to-fix-most-problems
Hi thanks, I have done the refresh/reset thing many times now in the last few months.

Also, I have made sure I've had no add ons, plug ins or themes active (only flash and cisco video codec are active). Entirely default set up, apart from my bookmarks.

I used to have 'tab mix plus' but removed it a couple of months ago as I thought it might be the reason. Didnt help.
The original report(s) were all due to OMTC. Can we get someone to test on a machine with a known-affected hardware config and figure out what's going on here? The number of dupes (and I suspect the ones marked aren't the only ones... see e.g. bug 1120215) is a bit alarming.
Flags: needinfo?(milan)
Bug 1103431 sounds like dupe.
Bug 1067470 sounds like a dupe or related, but has actually better analysis.
As of Firefox 36 stable, DISABLING OMTC causes random crashes in Firefox. I'm a user who has had ZERO crashes in Desktop Firefox in the last 2 years. I did notice the issue caused by OMTC a few versions ago, but tried to ignore it. Today morning I decided I had enough and discovered the "about:config" switch (disabling OMTC) which may alleviate the issue - but since my Firefox had already been upgraded to 36.0, it looks like I am suffering from a new issue.

This is very concerning, as MANY on the Firefox Support website are RECOMMENDING that OMTC be disabled if users are experiencing "freezing" in Firefox - but disabling OMTC in Firefox 36 is now causing CRASHES which is much more severe than a mere "freezing" of the UI! Essentially, your support structure is now worsening the issue...
(In reply to jmurugan.uw from comment #71)
> As of Firefox 36 stable, DISABLING OMTC causes random crashes in Firefox.
> I'm a user who has had ZERO crashes in Desktop Firefox in the last 2 years.
> I did notice the issue caused by OMTC a few versions ago, but tried to
> ignore it. Today morning I decided I had enough and discovered the
> "about:config" switch (disabling OMTC) which may alleviate the issue - but
> since my Firefox had already been upgraded to 36.0, it looks like I am
> suffering from a new issue.
> 
> This is very concerning, as MANY on the Firefox Support website are
> RECOMMENDING that OMTC be disabled if users are experiencing "freezing" in
> Firefox - but disabling OMTC in Firefox 36 is now causing CRASHES which is
> much more severe than a mere "freezing" of the UI! Essentially, your support
> structure is now worsening the issue...

I'd suggest that you file a bug for those crashes, if there hasn't been one already.

People are looking into this bug (and others related to it), but frankly it's a difficult one.
gfx.direct2d.disabled = true
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = true

Using those settings in about:config should fix the problem. Can anybody else confirm this?
Looking on whole discussion here and description it's definitely the same issue as in bug #1067470, so let's mark this bug as duplicate, as bug #1067470 has more info and devs attention.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(milan)
"layers.offmainthreadcomposition.enabled = false" fixes the tab close problem for me but the HTML5 player gets really slow.
Not Fixed
And hence not a duplicate of bug bug #1067470 which is now resolved.

THIS bug should be marked as unresolved. - It just happened to me again, waiting for several seconds for Firefox to unfreeze is a pain - when it happens a lot, including when closing these bug pages.
(In reply to kie000 from comment #77)
> And hence not a duplicate of bug bug #1067470 which is now resolved.
> 
> THIS bug should be marked as unresolved. - It just happened to me again,
> waiting for several seconds for Firefox to unfreeze is a pain - when it
> happens a lot, including when closing these bug pages.

Could you open a new bug report, with your add-ons list and the graphics section of the page about:support, please.
Same thing happening to me ALL the time and it is making me angry!!!! Mozilla, just bloody get rid of the bug NOW! ASAP! I am fed up! I have a brand new computer, upgraded with top notch quality parts, so don't need the freezing bug. It's wasting my time, every few seconds eats up my time when I am trying to work on things! Fix it ASAP!
(In reply to gypsysnail@hotmail.com from comment #79)
> Same thing happening to me ALL the time and it is making me angry!!!!
> Mozilla, just bloody get rid of the bug NOW! ASAP! I am fed up! I have a
> brand new computer, upgraded with top notch quality parts, so don't need the
> freezing bug. It's wasting my time, every few seconds eats up my time when I
> am trying to work on things! Fix it ASAP!

As noted in comment #78, please file a new bug report ( https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Firefox ) and include your about:support data (Help > Troubleshooting information).
@ gypsysnail@hotmail.com

The bug went away when I disabled my extensions, I've been enabling them one by one but haven't yet hit the one that causes the freezes.

List of (now disabled) extensions, one of which caused freezing:

Active Stop Button		1.5.1.1-signed		{9e96e0c4-9bde-49b7-989f-a4ca4bdc90bb}
Add-on Compatibility Reporter	2.0.6.1-signed		compatibility@addons.mozilla.org
BetterPrivacy			1.68.1-signed		{d40f5e7b-d2cf-4856-b441-cc613eeffbe3}
Blacken				2.1.18.1-signed		{09826eb2-625f-4909-a08f-9aff630abac3}
Color toggle			0.16.1-signed		background@toggle.wtf
Context Font			0.6.1-signed		contextfont@easel.org
Copy Plain Text 2		1.3.2.1-signed		copyplaintext@teo.pl
Disable clipboard manipulations	1.0.1.1-signed		nocopypaste@adblockplus.org
HTTPS-Everywhere		5.0.5			https-everywhere@eff.org
Remove It Permanently		1.0.6.10.1-signed	{1dbc4a33-ea62-4330-966c-7bdad3455322}
Saved Password Editor		2.9.1-signed		savedpasswordeditor@daniel.dawson
User Agent Switcher		0.7.3.1-signed		{e968fc70-8f95-4ab9-9e79-304de2a71ee1}
I can confirm the bug still exists in Firefox 39 for Mac. I usually close tabs using Command + W.

It's indeed very annoying.
rfischmann, Do you have any of the extensions that I listed?

I think 'Remove It Permanently' may be causing freezes.
Nope, I don't have any of those. Mine current add-ons: http://d.pr/i/IleR
You could disable half of your plugins and see if you still get freezes, then disable the other half to see if it's a plugin causing the prob, narrow it down that way.
After some research, I've disabled both "layers.offmainthreadcomposition.enabled" and "browser.tabs.animate" in about:config and things feel a bit better.

But the issue hasn't been fixed at all. I'll also test with the add-ons later, thanks.
You need to log in before you can comment on or make changes to this bug.