Closed
Bug 1065463
Opened 10 years ago
Closed 10 years ago
Firefox sometimes freezes for several seconds when closing tab with middle-click
Categories
(Core :: Graphics, defect)
Tracking
()
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.)
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
(note to self: might be related to bug 933733 / bug 896896, although the timeframe is somewhat off there (landed in 32))
Reporter | ||
Comment 3•10 years ago
|
||
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)
Reporter | ||
Comment 4•10 years ago
|
||
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
Comment 5•10 years ago
|
||
Thank you! I will have a look on Monday. :-)
Flags: needinfo?(gijskruitbosch+bugs)
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
(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)
Reporter | ||
Comment 8•10 years ago
|
||
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)
Reporter | ||
Comment 9•10 years ago
|
||
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"?
Comment 10•10 years ago
|
||
(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)
Comment 11•10 years ago
|
||
I don't have anything to add here. It doesn't look like something involving my areas of expertise, sorry.
Flags: needinfo?(n.nethercote)
Comment 12•10 years ago
|
||
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.
Comment 13•10 years ago
|
||
another topics from users with the same problem
http://www.reddit.com/r/firefox/comments/2k40zx/closing_tabs_or_switching_between_tabs_sometimes/
http://forums.mozillazine.org/viewtopic.php?f=9&t=2880521
Comment 15•10 years ago
|
||
Following the advice on mozillazine to disable OMTC seems to workaround bug. I have yet to experience a single hang since disabling it.
Comment 16•10 years ago
|
||
(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.
Comment 17•10 years ago
|
||
Redirecting needinfo to Milan based on comment #15 / comment #16.
Flags: needinfo?(bas) → needinfo?(milan)
Comment 18•10 years ago
|
||
> 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
Reporter | ||
Comment 19•10 years ago
|
||
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.
Comment 20•10 years ago
|
||
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)
Comment 21•10 years ago
|
||
Here's my graphics section:
http://pastebin.com/b1zCNrg2
Going to try gfx.direct2d.disabled now.
Comment 22•10 years ago
|
||
(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.
Comment 23•10 years ago
|
||
I'm having this exact issue in Firefox 33.
Comment 24•10 years ago
|
||
> Right-clicking on the page will also cause Firefox to wake up
true
Comment 25•10 years ago
|
||
Updating to 33.1 fixed it for me.
Comment 26•10 years ago
|
||
Nevermind, it still happens.
Comment 27•10 years ago
|
||
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.
Reporter | ||
Comment 28•10 years ago
|
||
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.
Comment 29•10 years ago
|
||
Freezes still occurs in Firefox 34.
Comment 30•10 years ago
|
||
Freezes still occurs in Firefox 34.0.5
Comment 31•10 years ago
|
||
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.
Comment 32•10 years ago
|
||
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.
Comment 33•10 years ago
|
||
(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
Comment 34•10 years ago
|
||
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)
Comment 35•10 years ago
|
||
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)
Reporter | ||
Comment 36•10 years ago
|
||
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.
Comment 37•10 years ago
|
||
(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.
Comment 38•10 years ago
|
||
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.
Comment 39•10 years ago
|
||
Clearly not a malware issue, this bug came with FF33.
Comment 40•10 years ago
|
||
(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.
Comment 41•10 years ago
|
||
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
Comment 43•10 years ago
|
||
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
Comment 44•10 years ago
|
||
It seems only Nvidia cards are affected. Am I wrong?
Comment 45•10 years ago
|
||
(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
Comment 46•10 years ago
|
||
(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.
Comment 47•10 years ago
|
||
(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.
Reporter | ||
Comment 48•10 years ago
|
||
(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
Comment 50•10 years ago
|
||
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
Comment 51•10 years ago
|
||
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
Comment 52•10 years ago
|
||
(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)
Comment 53•10 years ago
|
||
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.
Comment 55•10 years ago
|
||
Same problem as in https://bugzilla.mozilla.org/show_bug.cgi?id=1111078
Profile just after freeze https://dl.dropboxusercontent.com/u/10264719/f_FvPRLr
Comment 56•10 years ago
|
||
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.
Reporter | ||
Comment 57•10 years ago
|
||
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.)
Comment 58•10 years ago
|
||
I just want to confirm that this issue is still happening in 35.0.1 today.
Comment 59•10 years ago
|
||
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.
Comment 60•10 years ago
|
||
(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.
Comment 61•10 years ago
|
||
(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?
Updated•10 years ago
|
Flags: needinfo?(scottstown)
Flags: needinfo?(aklotz)
Comment 62•10 years ago
|
||
(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?
Comment 63•10 years ago
|
||
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.
Comment 64•10 years ago
|
||
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.
Comment 65•10 years ago
|
||
(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.
Comment 66•10 years ago
|
||
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
Comment 67•10 years ago
|
||
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.
Comment 68•10 years ago
|
||
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)
Comment 69•10 years ago
|
||
about:support info
http://pastebin.com/UMrg37r1
Reporter | ||
Comment 70•10 years ago
|
||
Bug 1103431 sounds like dupe.
Bug 1067470 sounds like a dupe or related, but has actually better analysis.
Comment 71•10 years ago
|
||
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...
Comment 72•10 years ago
|
||
(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.
Comment 73•10 years ago
|
||
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?
Comment 74•10 years ago
|
||
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: 10 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
Flags: needinfo?(milan)
Comment 75•9 years ago
|
||
"layers.offmainthreadcomposition.enabled = false" fixes the tab close problem for me but the HTML5 player gets really slow.
Comment 76•9 years ago
|
||
Not Fixed
Comment 77•9 years ago
|
||
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.
Comment 78•9 years ago
|
||
(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.
Comment 79•9 years ago
|
||
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!
Comment 80•9 years ago
|
||
(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).
Comment 81•9 years ago
|
||
@ 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}
Comment 82•9 years ago
|
||
I can confirm the bug still exists in Firefox 39 for Mac. I usually close tabs using Command + W.
It's indeed very annoying.
Comment 83•9 years ago
|
||
rfischmann, Do you have any of the extensions that I listed?
I think 'Remove It Permanently' may be causing freezes.
Comment 84•9 years ago
|
||
Nope, I don't have any of those. Mine current add-ons: http://d.pr/i/IleR
Comment 85•9 years ago
|
||
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.
Comment 86•9 years ago
|
||
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.
Description
•