User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20140911191954 Steps to reproduce: Sometimes, after switching from one tab to another one in Firefox 33 beta, Firefox looks like being frozen/hanging. Actual results: Sometimes, after switching from one tab to another one, Firefox looks like being frozen/hanging. But after switching to another _application_ and then switching back to Firefox window, it works fine, and tab is actually already switched to the one that I intended to switch before Firefox has been frozen. Note that this does not occur always, just sometimes, so it's hard to determine what exact 33.x build has introduced the bug. FWIW, I use Windows 7 Home Premium as OS. Expected results: Firefox should repaint its window correctly when switching tabs — without looking hanging — i.e. Firefox should work just as Firefox 32 and earlier versions before Firefox 33.

Confirming bug. Hardware acceleration: disabled User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

Some additional observations so far: * Window is also (besides switching-to-another-application trick) repainted if: * to click a button on a Firefox toolbar; * a tab tooltip has been shown. * Looks like content of target tab (i.e. the tab that user has switched to, but does not see it) is functional (though invisible): e.g. links on the tab can be hovered by mouse since moving the mouse leads to changing mouse cursor to pointer on some areas (and those areas do not correspond to where are links in the previous tab's contents), and clicking such links seems to lead to loading corresponding URLs [though they are invisible too], etc.).

Is it possible to find a regression range for this bug? https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ jrmuizel - based on the description of the bug, do you know where or to whom we should direct this bug? It sounds like Graphics...

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #3) > Is it possible to find a regression range for this bug? That's unlikely given that the bug appears quite randomly and not very frequently (a few times per day). What I can say quite certainly is that the bug is introduced in Firefox 33 (the bug symptoms didn't occur in Firefox 32), so the first step in resolving the bug is probably to find all fixed-in-Firefox-33 bugs that are related to graphics/rendering.

Didn't encounter the bug several days (approx. since Beta 6 or 7), so marking it as WFM for now. Will reopen if I will encounter the bug again.

Still seeing the bug on Aurora, reopening. User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

Observed the bug again too in the current Firefox 33 Beta 8 (20140929180120), unfortunately.

Same with Firefox 33 stable.

This bug can affect both content and chrome. Screenshot shows the tab-bar not rendering/updating properly after switching tab.

Tried a new clean profile with the latest Firefox 34 beta, same result. This bug literally ruins user experience and Firefox as a usable and competitive product. Sadly. Downgraded to Firefox 31 ESR (would use Fx 32 ESR as a pre-bug major version if it existed) to prevent encountering the bug at least for several months until a next ESR release with the hope that the bug will be fixed by that time. By the way, there were repainting issues in Firefox 33 (Fennec) for ARM on a tablet (e.g. a checkbox state did repaint only after scrolling page to a position where checkbox is out of visible area of browser and then scrolling back to see the checkbox with new state applied; also bottom parts of some pages were permanently pixelated as immediately after scrolling), and they were also resolved by downgrading to 31 ESR. The reason is probably the same as with this bug — a serious graphics-wise change in Gecko as of 33.x.

(In reply to Marat Tanalin | tanalin.com from comment #10) > Tried a new clean profile with the latest Firefox 34 beta, same result. Clean profile as in without extensions or plugins enabled?

(In reply to comment #11) > Clean profile as in without extensions or plugins enabled? Totally clean profile with no extensions. As for plugins, they are not a part of any profile, and the only two enabled ones were Adobe Acrobat 11.0.9.29 (disabled in my main profile by the way) and Shockwave Flash 15.0.0.223.

Marat, could to test with OMTC disabled? I believe all you need to do is set "layers.offmainthreadcomposition.enabled" to false in about:config.

(In reply to comment #13) > Marat, could to test with OMTC disabled? OK, switched to latest Firefox Beta again and set `layers.offmainthreadcomposition.enabled` to `false`, will see if it helps (at least several extra days are needed for more or less representative statistics due to spontaneous nature of the bug). Thanks. P.S. Tried to disable the parameter in Firefox 33 for Android too to overcome its repainting issues, but then _all_ pages (including `about:config` itself; the only exception I've seen was `about:home`) were rendered blank (though thumbnails to the left of the screen seemed to render correctly), and I was't even be able to switch the parameter back to `true`. So at least for Android, it doesn't help (and even quite the contrary). Switched back to 31 ESR again as for Android version of Firefox.

(In reply to Marat Tanalin | tanalin.com from comment #14) > (In reply to comment #13) > > Marat, could to test with OMTC disabled? > > OK, switched to latest Firefox Beta again and set > `layers.offmainthreadcomposition.enabled` to `false`, will see if it helps > (at least several extra days are needed for more or less representative > statistics due to spontaneous nature of the bug). Thanks. Yeah, I know. I'm trying to figure out what's causing this, and since you mentioned this started with v33 I figured the release notes for v33 could be a good start. OMTC was enabled by default on Windows in v33, and if we can determine if this is the root of the bug, we might have a chance of helping some dev fix this. :) Finding a regression window for this is almost impossible. I thought flash or some other plugin could be to blame, or perhaps noscript, but since you're experiencing the bug without any extensions that can't be it (I think?). > P.S. Tried to disable the parameter in Firefox 33 for Android too to > overcome its repainting issues, but then _all_ pages (including > `about:config` itself; the only exception I've seen was `about:home`) were > rendered blank (though thumbnails to the left of the screen seemed to render > correctly), and I was't even be able to switch the parameter back to `true`. > So at least for Android, it doesn't help (and even quite the contrary). > Switched back to 31 ESR again as for Android version of Firefox. I don't believe you mentioned having (similar?) problems on Android before? It might be a good idea if you filed another bug for that.

I wonder if bug 875209 is related.

Doh, one too many. Re-adding NEEDINFO: jmuizelaar@mozilla.com. Jeff, please see https://bugzilla.mozilla.org/show_bug.cgi?id=1067470#c3 for the original NEEDINFO request.

Ignore the smudged text, that's not due to the bug.

(In reply to Johan C from comment #15) > OMTC was enabled by default on Windows in v33, and if we can > determine if this is the root of the bug Well, during 10 days of using Firefox with OMTC disabled, I didn't encounter the bug at all. Once I've enabled OMTC as an experiment, I did encounter the bug again the same day. So it's quite probable that OMTC is the reason of the bug. BTW, I'm now using Firefox 35 Beta instead of Firefox 34 Beta. What I've noticed is that, with OMTC disabled, new tabs are created without animation, and content area of the new tab is rendered with a delay (probably equal to duration of the invisible tab animation) while, with OMTC enabled, new tabs are created with animation and content area of the new tab is rendered immediately, without a delay. Such delay creates some effect of browser's permanent lower-responsiveness, so disabling OMTC is not quite painless as for user experience (even aside from losing potential advantages of the OMTC itself). By the way, it seems that Firefox 35 Beta for Android has fixed the two bugs that I've mentioned in the comment 10 (checkboxes are now repainted correctly, and there is no permanent pixelation of bottom part of webpages anymore).

> with OMTC disabled, new tabs are created without > animation, and content area of the new tab is rendered with a delay Looks like that once I've written about the tab animation issue taking place when OMTC is disabled, tab animations have suddenly started to work, and delay has gone. Maybe switching the `layers.offmainthreadcomposition.enabled` pref from `false` to `true` and back has somehow resulted in this "self-fixing", or this is a consequence of updating Fx 35 Beta 1 to Beta 2 occured yesterday, or this is yet another bug that appears and disappears spontaneously.

I can still confirm this on latest Nightly.

Confirmed also here, on both Nightly: x86 and x64, STR is quite easy, open few tabs and start switch between them, after some short time You can see graphics glitches on tabs as mentioned in comment 0 plus site painting problems, kind of artifacts. OMTC disabled, HWA enabled.

Yeah, I don't think there's much that I can say about this with out a regression window. If people can run this program during the black screen and post the crash report from about:crashes http://people.mozilla.org/~jmuizelaar/crash-firefox.exe

I started using HWA on my main firefox-profile and don't remember seeing the bug since. However I'm running a bunch of other firefox-profiles less frequently where HWA is disabled and it looks like the bug still exists. But seeing as semtex reports in comment #22 that he's seeing the bug with HWA enabled I don't know if this is relevant. (In reply to Jeff Muizelaar [:jrmuizel] from comment #23) > If people can run this program during the black screen and post the crash > report from about:crashes > > http://people.mozilla.org/~jmuizelaar/crash-firefox.exe With HWA disabled and e10 enabled on Nightly 37.0a1 (pre https://hg.mozilla.org/mozilla-central/rev/7b33ee7fd162): The bug appeared in a "Warning: Unresponsive Script"-popup. Crashed Nightly with crash-firefox.exe Crash report: https://crash-stats.mozilla.com/report/index/342d7476-bc0e-443f-a101-fce852141221 (In reply to Jeff Muizelaar [:jrmuizel] from comment #23) > Yeah, I don't think there's much that I can say about this with out a regression window. While not exactly a regression window, it looks like the bug appeared in Firefox 33. Please let me know if I can provide additional information to the crash report.

(In reply to Johan C from comment #24) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #23) > > If people can run this program during the black screen and post the crash > > report from about:crashes > > > > http://people.mozilla.org/~jmuizelaar/crash-firefox.exe > With HWA disabled and e10 enabled on Nightly 37.0a1 (pre > https://hg.mozilla.org/mozilla-central/rev/7b33ee7fd162): > The bug appeared in a "Warning: Unresponsive Script"-popup. Crashed Nightly > with crash-firefox.exe > Crash report: > https://crash-stats.mozilla.com/report/index/342d7476-bc0e-443f-a101- > fce852141221 > How are you disabling HWA? That crash report suggests that HWA is not disabled.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #25) > How are you disabling HWA? That crash report suggests that HWA is not > disabled. My mistake, HWA is enabled. I must have enabled it to debug something, it's usually not enabled on Nightly.

After auto-updating from Firefox 35 beta to Firefox 36 beta, YouTube.com has started to crash my Firefox almost always when trying to play any video if `layers.offmainthreadcomposition.enabled` is `false` (verified with a new clean profile -- it does not crash if the pref is `true` and does crash if it's `false`). So disabling OMTC is not a viable solution anymore, but with OMTC enabled I will almost certainly encounter the repainting bug again (with OMTC disabled, I didn never encounter the bug AT ALL). FWIW, other video hostings (both Flash-based like rutube.ru and HTML5-Video-based like vimeo.com) do not cause Firefox crashes like YouTube does.

(In reply to Marat Tanalin | tanalin.com from comment #28) > So disabling OMTC is not a viable solution anymore, but with OMTC enabled I > will almost certainly encounter the repainting bug again (with OMTC > disabled, I didn never encounter the bug AT ALL). Sorry, that's my bad, I didn't mean for you to use it as a workaround. The idea was to see if you still encountered the bug with OMTC disabled.

(In reply to Johan C from comment #29) That's clear, but until the bug is fixed, disabling OMTC _was_ a good workaround anyway. And unfortunately it isn't anymore -- something in Fx 36 (added/changed compared with Fx 35) is probably relying on OMTC enabled and does not take into account that it can be disabled. A probable YouTube-related candidate reason of crashes according to Firefox 36 Beta Notes (https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/ ) is: "Implemented a subset of the Media Source Extensions (MSE) API to allow native HTML5 playback on YouTube". But setting `media.mediasource.enabled`, `media.mediasource.mp4.enabled`, and `media.mediasource.youtubeonly` to `false` does not fix the crashing issue.

(In reply to Marat Tanalin | tanalin.com from comment #30) > That's clear, but until the bug is fixed, disabling OMTC _was_ a good > workaround anyway. And unfortunately it isn't anymore -- something in Fx 36 > (added/changed compared with Fx 35) is probably relying on OMTC enabled and > does not take into account that it can be disabled. Have you tried with HWA (hardware acceleration) on and off? HWA has diminished the issue for me.

(In reply to Johan C from comment #31) Looks like disabling hardware acceleration solves the YouTube-crash issue, thanks. But then Firefox-UI fonts get somewhat blurry.

Filed bug 1123081 about YouTube-related crashing of Firefox 36 beta.

This seems like excessive duping around to me *shrug*. I didn't see this bug until around the time bug 1107297 landed on Nightly, about a month ago now. I can't really confirm that bug as the cause since this happens very rarely for me, but I never saw this before Firefox 37.

Sorry for this, but the same issues need to be duped to only one bug, so it won't be too much havoc. I still see it sometimes on Nightly 38, so definitely it's still not fixed yet and before I saw this issue on Nightly 34. [Tracking Requested - why for this release]: per bug #1108499 comment 33 needinfo?: per per bug #1108499 comment 31

I still haven't been able to reproduce this, does anyone have more reliable STR than just trying to switch tabs for half an hour :)?

Im pretty sure the cause is OMTC. This bug seems to be the same. https://bugzilla.mozilla.org/show_bug.cgi?id=1103431 It has link to mozillazine forums where it seems people confirm that switching OMTC off stops the bug from occurring.

(In reply to kalviskajaks from comment #43) > Im pretty sure the cause is OMTC. This bug seems to be the same. > https://bugzilla.mozilla.org/show_bug.cgi?id=1103431 It has link to > mozillazine forums where it seems people confirm that switching OMTC off > stops the bug from occurring. Nope, I don't use OMTC and I'm still able to reproduce this bug without problem....

Are you sure you have "layers.offmainthreadcomposition.enabled" set to false in about:config ?

(In reply to kalviskajaks from comment #45) > Are you sure you have "layers.offmainthreadcomposition.enabled" set to false > in about:config ? You Was right, this entry was set to "true", this is very strange, since main OMTC option is flipped to off, this still influence my browser, after changing to "false" problem was gone but browser start crashing on YT movies, there is another bug with this problem. So, we have workaround....

It clearly sucks when the browser gets into this state. However, as this is an intermittent issue that is difficult to reliably reproduce, I'm not going to track. We should fix this issue and should determine whether we can uplift a fix once we have one.

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #48) > It clearly sucks when the browser gets into this state. However, as this is > an intermittent issue that is difficult to reliably reproduce, I'm not going > to track. We should fix this issue and should determine whether we can > uplift a fix once we have one. As an unfortunate result of all the duplicating that happened, the tracking flags from bug 1108499 were lost. Can they not carry over? See bug 1108499 comment 33.

Thank you for highlighting bug 1108499 as a dup. The description in that bug sounds much more severe than the description in this bug. Given that there seems to be a larger issue here, I will revert my decision in comment 48 and track this bug. Milan - Not sure how we can make progress here as Bas is unable to reproduce. ni simply to flag this for you. (I don't expect a miracle answer.)

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #50) > Thank you for highlighting bug 1108499 as a dup. The description in that bug > sounds much more severe than the description in this bug. For what it's worth: for me, the bug's symptom is exactly what I've described: Firefox window is just not repainted after switching (or closing) a tab; there is no any mixing of content of different tabs for me.

Yeah, not sure where to take this - except to add that I've actually seen the "no repaint" (white, not black) on OS X! - 36 beta. Nothing I could do would repaint the part of the chrome between the tab and the window border (including minimizing and re-opening the window.) Leaving NI, maybe I can reproduce it (this was on the Air, Yosemite.)

Never seen it on OS X myself, but had it on two Windows machines, one with AMD, one with Intel graphics. Another possibly related graphical glitch is that when closing other than the last, the last tab would stay visibly floating and not slide to fill the empty space. I've disabled OMTC earlier today while leaving HWA enabled, and haven't seen it so far.

Milan, Clint has been working to get a company to help us on graphic tests. Maybe they can reproduce it. Anyway, with OMTC unsupported, we need to come up with a workaround.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #23) > Yeah, I don't think there's much that I can say about this with out a > regression window. > > If people can run this program during the black screen and post the crash > report from about:crashes > > http://people.mozilla.org/~jmuizelaar/crash-firefox.exe I manged to ctach one i think, not sure if useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085-56f252150129

(In reply to kalviskajaks from comment #55) > I manged to ctach one i think, not sure if > useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085- > 56f252150129 Unfortunately it's misleading tail. I had the same crash signature when I force crash Nightly when we had bug #1064864 (some more info in dupe bug #1060726)

(In reply to Virtual_ManPL [:Virtual] from comment #56) > (In reply to kalviskajaks from comment #55) > > I manged to ctach one i think, not sure if > > useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085- > > 56f252150129 > > Unfortunately it's misleading tail. > I had the same crash signature when I force crash Nightly when we had bug > #1064864 (some more info in dupe bug #1060726) Would running the profiler in this https://bugzilla.mozilla.org/show_bug.cgi?id=1060726#c2 comment be useful? And if yes, do i need to force the crash in comment 23 too or just run the profiler?

(In reply to Virtual_ManPL [:Virtual] from comment #56) > (In reply to kalviskajaks from comment #55) > > I manged to ctach one i think, not sure if > > useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085- > > 56f252150129 > > Unfortunately it's misleading tail. > I had the same crash signature when I force crash Nightly when we had bug > #1064864 (some more info in dupe bug #1060726) I got a profile while the bug was hapening. How do i share it? The share button didnt work because it was bigger than 9 mb.

I uploaded it on google drive. https://drive.google.com/file/d/0B3HpUUJxyc0ad21ZdVlOVl9ndEU/view?usp=sharing

Benoit, can you take a look at the profile from comment 59?

This is a correctness bug. I'm not sure what we expect to see from a performance profile. But I looked anyways and I don't see any samples preparing D3D11 commands, just the present call. Probably means we're not compositing a full frame. We've already found the root of the problem here: https://bugzilla.mozilla.org/show_bug.cgi?id=1108499#c31 You can see my try run to see the patch I did which disables the partial present. Looks like we landed a fix for it rencently in bug 1117925. Can someone reproduce this using a nightly build since the 23th?

(In reply to Benoit Girard (:BenWa) from comment #61) > This is a correctness bug. I'm not sure what we expect to see from a > performance profile. But I looked anyways and I don't see any samples > preparing D3D11 commands, just the present call. Probably means we're not > compositing a full frame. > > We've already found the root of the problem here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1108499#c31 > > You can see my try run to see the patch I did which disables the partial > present. > > Looks like we landed a fix for it rencently in bug 1117925. Can someone > reproduce this using a nightly build since the 23th? -_- yes 2 times already comment 55 and comment 58-59 is me running an updated nightly build on the 29th...

Ahh sorry! Can you try this build then? It did the trick in bug 1117925, it did the job there. I had to retrigger it since it expired: https://treeherder.mozilla.org/#/jobs?repo=try&revision=38982cccce8f Once it's ready I'll post the link. Just download it, unzip, close your Firefox session, run and reproduce the problem.

Sledru, without clear steps on how to repro it, I can't get the offsite team a way to test it. I can have them swap tabs a couple of times, but it's not clear that would really do the trick. :-(

(In reply to Benoit Girard (:BenWa) from comment #63) > Ahh sorry! Can you try this build then? It did the trick in bug 1117925, it > did the job there. I had to retrigger it since it expired: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=38982cccce8f > > Once it's ready I'll post the link. Just download it, unzip, close your > Firefox session, run and reproduce the problem. Was there supposed to be a download link somewhere on that page? If yes i cant find it. And its still happening http://i.imgur.com/eY861MQ.png only the middle part should have been there, the things on the sides are bleeding in from the reddit tab... And it happened again while i was uploading the picture.. All this with the latest nightly! It definitely isn't fixed. I cant take it anymore..

one more picture, it even happens on the new tab page. http://i.imgur.com/OFT2SLv.png

(In reply to kalviskajaks from comment #65) > Was there supposed to be a download link somewhere on that page? If yes i > cant find it. It's kinda hidden, if you don't know where to look ;) http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-38982cccce8f/try-win32/

Yes, please use this one: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-38982cccce8f/try-win32/firefox-37.0a1.en-US.win32.zip Make sure to close firefox to unlock your profile otherwise youll get either an error message or it will just open a window from your release version.

Could not trigger this bug with the linked build. Instead i got the tab freezes again like in bug 1103431 which did not happen in the regular nightly anymore.

I guess it is not going to be fixed for 36.

Milan, BenWa - This bug has been kicking around for a while. We don't seem to have good ideas on how to get additional information for you. Do you have any ideas on how to make progress?

Bas, the problem is caused by the code here: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/LayerManagerComposite.cpp#285 If we don't have a fix in the pipeline we should disable this code. This will probably stop us from doing the partial present.

Note: There's a *tiny* chance that this is caused by bug 1109314.

To Mozilla developers: guys, given that there are _manual_ user actions that ALWAYS force window repainting (e.g. pressing a toolbar button or appearing a tooltip of a content link or of a GUI element like tab title), why not just add an equivalent _automatic_ repainting action to Firefox code itself (related to switching tabs) as a temporary fix? In other words, it should be enough to just repaint window forcedly every time a tab is switched. Then, when/if the actual reason of the bug will be found and fixed, this temporary workaround fix could be removed. But for now, Firefox users would not suffer anymore, and Firefox would not keep losing its users (by the way, market share of Firefox in Russia is now just 7.5%, and that's a real shame [1]). Thanks. [1] https://www.liveinternet.ru/stat/ru/browsers.html?period=month;lang=en

Again(In reply to Marat Tanalin | tanalin.com from comment #75) > To Mozilla developers: > > guys, given that there are _manual_ user actions that ALWAYS force window > repainting (e.g. pressing a toolbar button or appearing a tooltip of a > content link or of a GUI element like tab title), why not just add an > equivalent _automatic_ repainting action to Firefox code itself (related to > switching tabs) as a temporary fix? Unfortunately, this isn't really practical or possible. From a graphics point of view there's not really anything special about switching tabs. The best thing for anyone who can reproduce this is to see if they can get a regression window using the process described here: http://mozilla.github.io/mozregression/ That will go a long way in determining the cause of this problem.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #76) > Again(In reply to Marat Tanalin | tanalin.com from comment #75) Marat can you provide the graphics section of your about:support from a browser session that has seen this problem occur?

I can reproduce it within 1-2 minutes by close/restore same tab. I use Mouse Gesture Redox plugin with "down" gesture for closing and "up" for restoring. So it's easy to close and restore. Open a few tabs and cyclically close/restore the last one with down/up/down/up gesture. Sometimes closing "does not work" and I still see the tab, but it disappears after right click or something. Mouse Gesture Redox extension: https://dl.dropboxusercontent.com/u/235592644/files/{FFA36170-80B1-4535-B0E3-A4569E497DD0}.zip My about:support https://bugzilla.mozilla.org/show_bug.cgi?id=1065463#c69

(In reply to Jeff Muizelaar [:jrmuizel] from comment #76) > Unfortunately, this isn't really practical or possible. From a graphics > point of view there's not really anything special about switching tabs. Maybe I wasn't clear enough: I suggest to add a temporary _workaround_ (forced repaint on switching tabs) to Firefox code that will make the bug look fixed until Mozilla developers will be able to find and fix the actual reason of the bug. If I can guaranteedly unfreeze my Firefox by doing a certain action, the Firefox itself could automatically imitate this action. > The best thing for anyone who can reproduce this is to see if they can get a > regression window using the process described here: > http://mozilla.github.io/mozregression/ That's in fact inapplicable to this bug. Please see the comment 4. (In reply to Jeff Muizelaar [:jrmuizel] from comment #77) > Marat can you provide the graphics section of your about:support from a > browser session that has seen this problem occur? I already did this in bug 1123081 comment 5 (just with OMTC disabled), but here it is again (now with OMTC enabled as I currently use Firefox this way due to crashes introduced in Firefox 36 with OMTC disabled) (data obtained with Firefox 36 stable released on 2015-02-24): Adapter Description: NVIDIA GeForce GTX 650 Ti BOOST Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 2048 Device ID: 0x11c2 Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16492) Driver Date: 2-5-2015 Driver Version: 9.18.13.4752 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 356d1458 Vendor ID: 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 650 Ti BOOST Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

FWIW, I've just recorded a video (715 KB) demonstrating the bug: http://tanalin.com/_experimentz/bugs/fx/2014/repaint/video/ On video, you can see that Firefox window is repainted once title tooltip of a link in the invisible (but actually active) tab is shown.

> I can reproduce it within 1-2 minutes by close/restore same tab. I recorded a video: https://dl.dropboxusercontent.com/u/235592644/files/firefox_bugzilla_1067470.wmv.zip (643kb) Firefox "freezes" at 0:15 and unfreezes after more than a minute! (and tab finally closes) Unfortunately I was not able to reproduce it with FireGestures extension (which is on AMO) within 5 minutes. That's because I put the link to Gesture Redox extension (looks like it does not work with Nightly)

Can anyone reproduce this issue on hardware other than Nvidia?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #82) > Can anyone reproduce this issue on hardware other than Nvidia? I filed two of the duplicated bugs, and I'm on Intel HD3000 - Win7. One of the bugs was with HW On and the other one with HW off. But both with OMTC On.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #82) > Can anyone reproduce this issue on hardware other than Nvidia? I filed dupe bug #1130437 and I'm also Intel HD3000 Win 7 x64. Note I'm using x64 builds. The bug includes a video showing what happens and as noted was reproducible with HWA on or off. Since I filed that bug it has not happened a single time. I think maybe there is something I was doing that was CPU intensive, or something, that made it easier for the bug to show itself at that time. Also, since filing that bug I've disabled OMTC due to another bug so that may be why I haven't encountered it. Just now I tried for ten minutes in a clean profile to reproduce and I can't. Sorry but I can't devote the cumulative amount of time that would be required in my case to create a regression window. It would probably be hours.

Tomorrow I'm going to try to put together a debugging build that people can try which should give us some idea of whether the failure is at the driver level or at a higher one.

Running this build from cmd.exe with the -attach-console flag should print something everytime we try to draw something to the screen. I'd be very interested in seeing the results when firefox stops painting. Do we still print anything? Does the output change? http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-38de7daa04da/try-win32/

umm do we attach the flag to the cmd.exe or firefox.exe?

(In reply to kalviskajaks from comment #87) > umm do we attach the flag to the cmd.exe or firefox.exe? Firefox.exe

That build had a small bug in it: there should be a new build showing up once this is done: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8e9c6d603d21 But results from the first build will still contain some useful information.

> should print something everytime we try to draw something to the screen It prints only few lines at startup: d:\!temp\firefox>firefox -attach-console -p d:\!temp\firefox>221051652 EndFrame: Present 221051284 EndFrame: Present 221051456 EndFrame: Present 221051652 EndFrame: Present 221051652 EndFrame: Present 221051652 EndFrame: Present 221051652 EndFrame: Present > there should be a new build no link there

correct link: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-8e9c6d603d21/try-win32/ > It prints only few lines at startup Ok, it does work without -p

Can you please add a counter or/and timestamp to the output? It's hard to answer your question if you have full window with same line "0 EndFrame: Present"

(In reply to 65feb6b8c9726133b18ac2f2ac26e8bc from comment #92) > Can you please add a counter or/and timestamp to the output? It's hard to > answer your question if you have full window with same line "0 EndFrame: > Present" Gah, sorry, that was my original intent. A build that properly increments will show up here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a547c98975d2

(In reply to Jeff Muizelaar [:jrmuizel] from comment #94) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #93) > > Gah, sorry, that was my original intent. A build that properly increments > > will show up here: > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=a547c98975d2 > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla. > com-8e9c6d603d21/try-win32/ Wrong link...

(In reply to Jeff Muizelaar [:jrmuizel] from comment #95) > Wrong link... I assume you meant http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-a547c98975d2/try-win32/

(In reply to anonbugreport from comment #96) > I assume you meant > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla. > com-a547c98975d2/try-win32/ Yep.

A key piece of information I'd like to know is if it's possible to get Firefox to print these messages while it has stopped painting, or if they stop and don't start until Firefox starts painting again.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #98) > A key piece of information I'd like to know is if it's possible to get > Firefox to print these messages while it has stopped painting, or if they > stop and don't start until Firefox starts painting again. I finally managed to get Firefox to freeze while switching tabs with your build. All I get was "EndFrame: Present". The console continues printing that while I hover the cursor over the unpainted links, just like it would if the tab did not freeze. The freeze did not stop Firefox from printing the "EndFrame: Present" messages.

I want to confirm what Marat Tanalin posted above - 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 which may alleviate the issue - but since my Firefox had already been upgraded to v36, it looks like I am suffering from the issue Marat pointed out. This is very concerning, as MANY of those 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 anonbugreport from comment #99) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #98) > > A key piece of information I'd like to know is if it's possible to get > > Firefox to print these messages while it has stopped painting, or if they > > stop and don't start until Firefox starts painting again. > > I finally managed to get Firefox to freeze while switching tabs with your > build. > All I get was "EndFrame: Present". > The console continues printing that while I hover the cursor over the > unpainted links, just like it would if the tab did not freeze. > The freeze did not stop Firefox from printing the "EndFrame: Present" > messages. Ok, this suggests that we are asking the driver to present our new frame. So either the driver is not actually presenting the new frame or we're not giving the driver any new data. If you enable the layers.acceleration.draw-fps preference does the frames per second counter change while Firefox is frozen, but the messages are still being printed?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #101) > Ok, this suggests that we are asking the driver to present our new frame. So > either the driver is not actually presenting the new frame or we're not > giving the driver any new data. There have been reports of this occurring on Nvidia, AMD, and Intel cards. Could it really be all three vendors have faulty drivers? My GPU information for reference: http://pastebin.com/x1MQg9nm > If you enable the layers.acceleration.draw-fps preference does the frames > per second counter change while Firefox is frozen, but the messages are > still being printed? The fps counter froze at "010 010 100" while the messages continue printing.

I've started a new build here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7abc29022042 It contains a little bit more logging and a square in the top left that will change color every time we try to Present. The square painting is at a very low level so if we have any ability to draw to the screen it should end up there. I'd be very interested to hear if anyone sees "EndFrame: Present" messages happening without the colored square changing.

This looks wrong: > if (color == 0xff0000ff) > color = 0xffff00ff; > else > color = 0xff00ffff; Won't this always end up with the else branch? -> Color not actually changing?

Also dstBox vs srcBox naming and UpdateSubresource afaik takes 5 input parameters (bitmap missing?)

/s/5/6

(In reply to Johannes Pfrang [:johnp] from comment #106) > /s/5/6 Yeah, this was the wrong version of the patch. The machine with the correct version isn't readily available to me, but I hope to have a new build started soon.

This should work better: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b14141aa78f7 https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-b14141aa78f7

(In reply to Jeff Muizelaar [:jrmuizel] from comment #108) > This should work better: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=b14141aa78f7 > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-b14141aa78f7 Messages continue printing as usual but the square froze.

(In reply to anonbugreport from comment #109) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #108) > > This should work better: > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=b14141aa78f7 > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > > jmuizelaar@mozilla.com-b14141aa78f7 > > Messages continue printing as usual but the square froze. Can others who see this bug confirm the same symptoms?

Symptoms about the original issue? Or about your try builds? About the main issue, I got some random freezes of the UI (almost impossible to reproduce) when switching to a tab, I have to right click to make the context menu appear or switch to another application window to have the hand again (left click) on the Firefox UI. If I do nothing, it seems to disappear automatically after a few seconds (maybe 5 or 6).

(In reply to Loic from comment #117) > Symptoms about the original issue? Or about your try builds? > > About the main issue, I got some random freezes of the UI (almost impossible > to reproduce) when switching to a tab, I have to right click to make the > context menu appear or switch to another application window to have the hand > again (left click) on the Firefox UI. > > If I do nothing, it seems to disappear automatically after a few seconds > (maybe 5 or 6). Same symptoms with the try builds. i.e. messages are printed in the console but the square in the top does not change color.

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?

(In reply to Pikamander2 from comment #119) Looks like you're effectively just disabling hardware acceleration which is a known workaround for the issue.

FWIW, starting from Firefox 37 beta, I now encounter not just freezes, but also displaying mixed contents of different tabs, which I did never see in Firefox 36 beta. Moreover, mixed content is then repainted partially (e.g. when I'm hovering different tiles on the new-tab page, the window is repainted in areas of specific tiles I've hovered), not entire window at once. So mixing content of different tabs is probably a separate bug different from what the current bug is about.

No, it's not the other bug, it's a known that the frozen tab content (e.g. like links) will be shown when you move your mouse cursor on it.

(In reply to Virtual_ManPL [:Virtual] from comment #122) But this wasn't the case for me until updating from v36 to v37. For example, see the video at the bug URL: once the link is showing title tooltip, the window is repainted entirely at once.

No idea if it's a different bug or not, but I can confirm what Marat Tanalin said is exactly what I encountered and it only happens from beta v37.

I still haven't seen any confirmation of the symptoms experiences by anonbugreport@mailinator.com in comment 109. Does anyone else see the same thing. I'm not that interested in FF37 results because 37 has partial present which will complicate the reporting further.

I have tried using your try build based on FF36 but it crashed continuosly, and I couldn't reach to see the bug. I tried creating lots of tabs, but it wasn't useful...

(In reply to marco_pal from comment #127) > I have tried using your try build based on FF36 but it crashed continuosly, > and I couldn't reach to see the bug. I tried creating lots of tabs, but it > wasn't useful... The crashes might be pointing at a problem. Can you try the build that shows up here? https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0fd3e9ab7052 It will hopefully not have the same crashes and give useful information.

In the old build firefox crashed on: -after a few characters typed in the location bar -when opening the dropdown box dialog for activating/disabling/ask in the plugin page -i'm not sure but also maybe when unloading flash The new one doesn't crash anymore but doing the same actions make the interface freeze. Not only the page but also the chrome is freezed. The colored box was freezed as well but in the console was printing continuosly "4422 EndFrame: Present 887a0005", the last number is always the same and before freezing is 0. I was in the addons page, the page somehow worked because using tooltips and mouse cursors I was able to move and change sections. I must mention that while the windows was completely freezed, dialog appeared, like the right click one and the "hamburger" dialog, both in page and in chrome. Even the preference window appeared without a problem. I must mention that while this happened the colored box didn't appear at all in these windows/dialogs while before crashing it appeared everywhere. The last thing I noted is that after freezing only the repainting in the freezed gui are reported but everything else (other dialogs) aren't printing messages as before. If I minimize the windows it becomes completely white. I can freeze the gui on demand in this build so if you want other info I'm here ;-)

A correction: in the new build the location bar dosn't seem to crash anymore, but in the addon page it crash also if I right click somewhere and not only in ask/deny menu of each plugin. I made a recording, in a few hours should be online and I try to post it here.

(In reply to marco_pal from comment #129) > In the old build firefox crashed on: > -after a few characters typed in the location bar > -when opening the dropdown box dialog for activating/disabling/ask in the > plugin page > -i'm not sure but also maybe when unloading flash > > The new one doesn't crash anymore but doing the same actions make the > interface freeze. Not only the page but also the chrome is freezed. The > colored box was freezed as well but in the console was printing continuosly > "4422 EndFrame: Present 887a0005", the last number is always the same and > before freezing is 0. 887a0005 is DXGI_ERROR_DEVICE_REMOVED. I've started a new build that will show up here that may give more information on what is happening. https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-57ece2616b0d Do you have any guesses as to what might be causing this error?

This builds doens't add anything new because it prints "73 EndFrame: Present 887a0005 reason 887a0005" ... I had problems uploading the video, now I'm trying with a different file hosting. I don't know what could be the culprit... However is there something different between this and the standard release builds? Because I don't have these problems in release. These bug was extremely rare to happen and it recovered after a few seconds, instead here crash a lot...

I realized I left another MOZ_CRASH in the build. Try the build that shows up here should crash less and give more information about the d3d11 device that we're using: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-3f977c607fc1

(In reply to Jeff Muizelaar [:jrmuizel] from comment #133) > I realized I left another MOZ_CRASH in the build. Try the build that shows > up here should crash less and give more information about the d3d11 device > that we're using: > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-3f977c607fc1 Your latest build produces similar results as before except that it prints "EndFrame: Present(1b6b3c, 12320d88) 0". I experienced no crash or any DXGI_ERROR_DEVICE_REMOVED errors. Though I managed to trigger the bug rather early at around the 3600th EndFrame. (In reply to marco_pal from comment #129) > I can freeze the gui on demand in this build so if you want other info I'm > here ;-) How exactly do you get the freeze to happen on demand? If it is 100% reproducible, I could see about getting that regression window.

(In reply to anonbugreport from comment #134) > Your latest build produces similar results as before except that it prints > "EndFrame: Present(1b6b3c, 12320d88) 0". Do the numbers inside Present change when the rendering stops/starts again?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #135) > (In reply to anonbugreport from comment #134) > > Your latest build produces similar results as before except that it prints > > "EndFrame: Present(1b6b3c, 12320d88) 0". > > Do the numbers inside Present change when the rendering stops/starts again? Nope. It stays the same. Only the counter at the start changes.

https://mega.co.nz/#!nQBBBThY!DjIHY7NnXBAn2EKcpgoh7yNRaOUfeDPbqsNFShVUj8M https://mega.co.nz/#!CYIlnb6b!7VsC5OxxqtZ5ad31F9HXR-s-LyMoI-dqt5I6jLKvgcw Here I'm am again, the first video was with the first build and the second with the latest one. The behavior isn't always exactly the same, it changes a little if I make it freeze using the button instead of using the right click, or something else... However I recorded this one because it seems to have more information. As you can see after it freeze the preference window that I open works but doesn't print or show a rectangle so it must render using another path. But you can also note two different things: the right click dialog that I use to freeze prints but doesn't appear; and there are also dialogs that show with a freezed rectangle while printing WITHOUT ERRORS. And during all of these the original device stays the same. At the end I make it crash using right click on the transparent bar but it doesn't always crash like that depending on what I press before.

What commands should I be using for mozregression? I assume since the bug was not present in Firefox 32 I should use the command "mozregression --bits 32 --good-release 32 --bad-release 33". This results in the following window. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9305a8ec77fe&tochange=9dc0ffca10f4 The tests was performed by holding down Ctrl+Tab to cycle through the tabs rapidly while occasionally right clicking a tab. The right clicking seems to help trigger the bug (It might just be placebo). Since I could not reproduce it consistently, I just went for brute force. Also while the bug is present in a clean profile, installing the addon Stylish seems to trigger it much more frequently.

@anonbugreport If you make the same actions as I do in the video, does it behave like mine? I mean freeze in the addon tab.

(In reply to marco_pal from comment #139) > @anonbugreport > If you make the same actions as I do in the video, does it behave like mine? > I mean freeze in the addon tab. I tried, but experienced no crash or blank context menu.

marco_pal I've split your issue out into a separate bug because it's more reproducible and has some different symptoms. The new bug is bug 1141073

anonbugreport can you try to figure out as much information about what causes the browser to start painting again after it stops?

clicking on other tabs/ minimizing maximizing = browser repaints moving mouse/waiting = never repaints ?

(In reply to kalviskajaks from comment #144) > clicking on other tabs/ minimizing maximizing = browser repaints > > moving mouse/waiting = never repaints ? How about switching the focus to another program and back to Firefox?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #145) > (In reply to kalviskajaks from comment #144) > > clicking on other tabs/ minimizing maximizing = browser repaints > > > > moving mouse/waiting = never repaints ? > > How about switching the focus to another program and back to Firefox? And how about switching to a tab that has the same title. Does that fix it?

How about resizing the window. Does that fix it?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #147) > How about resizing the window. Does that fix it? Yes, for me double clicking the window to make it full screen *does* fix the issue 100% of the time. I haven't tried manually dragging the window to a larger size though. The next time the issue occurs I can try this or switching to another program and back. (I'm the one who filed the duped bug 1140968 FWIW)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #143) > anonbugreport can you try to figure out as much information about what > causes the browser to start painting again after it stops? Right clicking (open context menu) Opening the options menu Switching window focus Minimizing Resizing Waiting (sometimes? not sure) Probably anything except interacting with the page normally. Scrolling, switching tabs, closing tabs, does not cause a repaint.

Not sure if it's still needed, I made a crash when not painting corrcectly: https://crash-stats.mozilla.com/report/index/6a52f94b-9030-4320-a5db-2fce52150311

anonbugreport, does the content of the tabs matter? Can you reproduce the bug using tabs that just contain about:blank?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #151) > anonbugreport, does the content of the tabs matter? Can you reproduce the > bug using tabs that just contain about:blank? We probably won't know if the bug occurred because we can't compare page content in about:blank as it doesn't have one.

(In reply to Virtual_ManPL [:Virtual] from comment #152) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #151) > > anonbugreport, does the content of the tabs matter? Can you reproduce the > > bug using tabs that just contain about:blank? > > We probably won't know if the bug occurred because we can't compare page > content in about:blank as it doesn't have one. The selected tab should show the tab not changing though.

This could just be a random coincidence, but I was regularly able to reproduce this bug for the last month, but for the last two days haven't gotten a single occurrence. The only thing I changed two days ago is removing a pinned tab with the following content: http://techblog.netflix.com/search/label/JavaScript (I never really looked at this tab, it was just a way of keeping a "todo" for something I wanted to read) I just added the pinned tab back and the bug reproduced! So maybe something to try.

Also, anonbugreport, is it possible for you to make a screencapture of you reproducing the problem?

(In reply to bugzilla_mozilla from comment #154) > This could just be a random coincidence, but I was regularly able to > reproduce this bug for the last month, but for the last two days haven't > gotten a single occurrence. The only thing I changed two days ago is > removing a pinned tab with the following content: > http://techblog.netflix.com/search/label/JavaScript (I never really looked > at this tab, it was just a way of keeping a "todo" for something I wanted to > read) > I just added the pinned tab back and the bug reproduced! So maybe something > to try. If you disable flash are you able to still able to reproduce the problem?

I'll try disabling flash after I've reproduced it a few more times so I can have a bit more confidence that the change is related. But I do have an answer to a prior question. I just reproduced the issue again and can confirm that putting focus on a different application and then returning focus to firefox *does* resolve the issue. The firefox window was not resized at all and the only click was on the upper part to refocus the window.

I have a new build coming up here that does a readback of the destination in an attempt to see if it's our writing to swap chain that's broken or the DWM's presentation of the frames. I'd also be interested to know if anyone can reproduce the problem with the DWM turned off.

(In reply to bugzilla_mozilla from comment #157) > I'll try disabling flash after I've reproduced it a few more times so I can > have a bit more confidence that the change is related. > > But I do have an answer to a prior question. I just reproduced the issue > again and can confirm that putting focus on a different application and then > returning focus to firefox *does* resolve the issue. The firefox window was > not resized at all and the only click was on the upper part to refocus the > window. Does it only happen with http://techblog.netflix.com/search/label/JavaScript pinned? or can you pin other tabs and reproduce the problem? Does http://techblog.netflix.com/search/label/JavaScript need to be pinned or can it just be open? What about using a single post from the blog like http://techblog.netflix.com/2015/01/netflix-likes-react.html? Does that help reproduce the problem?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #159) > (In reply to bugzilla_mozilla from comment #157) > > I'll try disabling flash after I've reproduced it a few more times so I can > > have a bit more confidence that the change is related. > > > > But I do have an answer to a prior question. I just reproduced the issue > > again and can confirm that putting focus on a different application and then > > returning focus to firefox *does* resolve the issue. The firefox window was > > not resized at all and the only click was on the upper part to refocus the > > window. > > Does it only happen with http://techblog.netflix.com/search/label/JavaScript > pinned? or can you pin other tabs and reproduce the problem? Does > http://techblog.netflix.com/search/label/JavaScript need to be pinned or can > it just be open? What about using a single post from the blog like > http://techblog.netflix.com/2015/01/netflix-likes-react.html? Does that help > reproduce the problem? All great questions! I'll try to get answers but it may take awhile due to the infrequency at which I can reproduce. I'm going to try to be methodical about it and record occurrences under different circumstances. Ideally I'd like to have a bunch of different occurrences before I move onto the next test, and each occurrence can take multiple hours of heavy usage. So stay tuned...

The bug is not related to pinning since I almost never pin anything yet experience the bug. The bug is solely related to tab creating/closing/switching.

(In reply to Marat Tanalin | tanalin.com from comment #161) > The bug is not related to pinning since I almost never pin anything yet > experience the bug. > > The bug is solely related to tab creating/closing/switching. It's possible different circumstances could tickle the same underlying issue, so I wouldn't be so quick to dismiss other investigation paths especially given that this bug has been open for 6 months with little progress and no reproducible cases.

There will be an even better build to test here: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0270fbc337a9

I'm also experiencing this issue, and was going to create a new ticket but I found this one already. It's difficult to reproduce as has been said, as it only happens occasionally. Sometimes if I'm switching from a text page to a you tube video, the box for the video will overlay the previous tab partially, as if the new tab is halfway loaded. When it does freeze, I simply minimize Firefox, and when I maximize again, the tab has switched. It seems like this has been talked about for a long time, so I'm probably no help here, but if I can help by giving more information, let me know.

Same here. Almost random and annoying issue.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #156) > If you disable flash are you able to still able to reproduce the problem? FWIW, the bug appears regardless of whether Flash is enabled or disabled. Tested on Firefox 38.0a2 (20150313004057, x64) with Flash disabled.

Has anyone had a chance to test this build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0270fbc337a9 with -attach-console ?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #167) > Has anyone had a chance to test this build: > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-0270fbc337a9 > > with -attach-console ? I can't get that build to freeze for some reason.

Can anyone else still reproduce the issue with this build? https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0270fbc337a9

I haven't seen this bug in the last few Nightlies (maybe the whole last week). If others confirm this, maybe it got fixed.

I think i have, but it goes away after a moment. It used to stay bugged if i didn't do anything, but now it just bugs out for like a halfsecond or less and goes back to normal. Either that or i have been just lucky and haven't triggered the bug so hard anymore. I use nightly. Haven't tried the build Jeff is offering.

Just made another crash for that. At least on beta, this bug is very frequent and painful as hell especially when you're browsing image intensive websites. https://crash-stats.mozilla.com/report/index/bp-38198586-947a-4011-ae60-5b9b52150317

(In reply to Guilherme Lima from comment #170) > I haven't seen this bug in the last few Nightlies (maybe the whole last > week). If others confirm this, maybe it got fixed. Just happened again on the lastest Nightly, so it was a false alarm.

(In reply to Benjamin Peng from comment #172) > https://crash-stats.mozilla.com/report/index/bp-38198586-947a-4011-ae60- > 5b9b52150317 Unfortunately it's misleading tail. I had the same crash signature when I force crash Nightly when we had bug #1064864 (some more info in dupe bug #1060726)

Please try reproducing with this build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0270fbc337a9

(In reply to Jeff Muizelaar [:jrmuizel] from comment #175) > Please try reproducing with this build: > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-0270fbc337a9 Used it a bit. Didnt encounter the bug yet. I do crash every time i try to use reddit search box though, which doesnt happen with newest nightly. https://crash-stats.mozilla.com/report/index/a6ecb114-51d8-470e-a0f8-257012150318

More crashing when interacting with the allow plugin box. https://crash-stats.mozilla.com/report/index/1dc19ad7-c0ac-4c6d-9806-3c09c2150318 And the flashing rectangle is right in the way in all menus while trying to use the browser. Would it be possible to place it at bottom right corner where there is usually blank space in all windows, if that isnt too hard?

Seems, like the crashes that I had a few comments ago. By the way, they happens in same way also in the latest build and with the same signature as you. However I'm not sure it's the same bug, as the crashes happens to me only in this trybuilds, on the release build the bug happens rarely and never crashes. It was splitted in another bug by Jeff, if you see the previous comments. I don't know if you're able to know something by the address in the crash report which are the same

Yes i see https://bugzilla.mozilla.org/show_bug.cgi?id=1141073 no progress there though.

I think this build might fix the crash: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-84df7b5a88d6/try-win32/ Can you see if you can reproduce with it?

Still crashing. Different signature, same trigger. https://crash-stats.mozilla.com/report/index/a62de196-cfe6-4d2a-9f34-4b4c32150319

There will be a new build here: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-822f176d0766 That should either not crash or print a message before it does crash.

The last build I think didn't worked. I also written a recap in the other bug.

Yes the directory is empty, unless its meant to take several days to compile or smth.

Yeah, that one had a build problem. I have a new one started that should show up here: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-fb557a9f924c/

(In reply to Jeff Muizelaar [:jrmuizel] from comment #186) > Yeah, that one had a build problem. I have a new one started that should > show up here: > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-fb557a9f924c/ https://crash-stats.mozilla.com/report/index/199d91f2-daee-4d89-bf72-bafc12150323 crash on using reddit search, log ended with °598 EndFrame: Present(a8f76c, 11fee6b0) 0 value: ffff58ff 599 EndFrame: Present(a8f76c, 23b39248) 0 value: ff0059ff 600 EndFrame: Present(a8f76c, 11fee6b0) 0 value: ffff5aff 601 EndFrame: Present(a8f76c, 11fee6b0) 0 value: ff005bff 602 EndFrame: Present(a8f76c, 11fee6b0) 0 Texture creation failed with 887a0005 and https://crash-stats.mozilla.com/report/index/3819e65e-50e6-4a17-b08b-c81272150323 crash on interacting with allow plugins box, log ended with 752 EndFrame: Present(6cacfc, 11ba7d90) 0 value: fffff2ff 753 EndFrame: Present(6cacfc, 11ba7d90) 0 value: ff00f3ff 754 EndFrame: Present(6cacfc, 11ba7d90) 0 Texture creation failed with 887a0005

Some random thoughts: This bug is more often when viewing image-heavy tabs. It almost guaranteed to happen when I switch between two tabs with large resolution images (4000x5000+). It's much easier to happen when I use Firefox for a while, instead of just opened it. So memory usage could be quite relevant to Firefox's rendering efficiency/performance. And it rarely happens when I'm testing in safe mode (still happens, but way less frequent) so it means (a lot of) addons would aggravate the issue.

(In reply to kalviskajaks from comment #189) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #186) > > Yeah, that one had a build problem. I have a new one started that should > > show up here: > > > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > > jmuizelaar@mozilla.com-fb557a9f924c/ > > https://crash-stats.mozilla.com/report/index/199d91f2-daee-4d89-bf72- > bafc12150323 > > crash on using reddit search, log ended with > > °598 EndFrame: Present(a8f76c, 11fee6b0) 0 > value: ffff58ff > 599 EndFrame: Present(a8f76c, 23b39248) 0 > value: ff0059ff > 600 EndFrame: Present(a8f76c, 11fee6b0) 0 > value: ffff5aff > 601 EndFrame: Present(a8f76c, 11fee6b0) 0 > value: ff005bff > 602 EndFrame: Present(a8f76c, 11fee6b0) 0 > Texture creation failed with 887a0005 > > and > https://crash-stats.mozilla.com/report/index/3819e65e-50e6-4a17-b08b- > c81272150323 > > crash on interacting with allow plugins box, log ended with > > 752 EndFrame: Present(6cacfc, 11ba7d90) 0 > value: fffff2ff > 753 EndFrame: Present(6cacfc, 11ba7d90) 0 > value: ff00f3ff > 754 EndFrame: Present(6cacfc, 11ba7d90) 0 > Texture creation failed with 887a0005 Same for me, same crashes also https://crash-stats.mozilla.com/report/index/e795cd8d-c1fa-4f07-af16-92c3e2150320

We're now at the end of the 37 cycle. As we have shipped 3 releases with this bug already, I'm not going to block on this issue for 37. Please keep pushing for 38 as we absolutely do want to fix this as soon as we can identify the source of the problem.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #186) > Yeah, that one had a build problem. I have a new one started that should > show up here: > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-fb557a9f924c/ How are we supposed to use this? Can it be the zip build? I ran "firefox -attach-console -p -no-remote" and nothing is printed on cmd.exe, is that it?

(In reply to Rodze from comment #194) > How are we supposed to use this? Can it be the zip build? > > I ran "firefox -attach-console -p -no-remote" and nothing is printed on > cmd.exe, is that it? The zip build works. It just doesn't work with "-p".

I found a way to replicate the freeze at least on my machine, the key beeing windows tooltips: 1. Open several Firefox tabs. 2. Move the mouse at the tab header of an inactive tab and at the very moment the tooltip appears, click the mouse to switch to that tab. You not always get the timing right, as you have to be very quick. In short: If tooltip is displayed at the same moment while the tab is getting activated, the tab freezes.

(In reply to Miks from comment #196) > I found a way to replicate the freeze at least on my machine, the key beeing > windows tooltips: > 1. Open several Firefox tabs. > 2. Move the mouse at the tab header of an inactive tab and at the very > moment the tooltip appears, click the mouse to switch to that tab. You not > always get the timing right, as you have to be very quick. > > In short: If tooltip is displayed at the same moment while the tab is > getting activated, the tab freezes. WOW. Ingenious finding.. I can reproduce it.

I should mention it's not always "reproducible". You need to use Firefox for a while (better in a heavy profile) until it became kinda "lagging"; and then this trick would produce the rendering bug every time you click at the exact momennt he said.

(In reply to Benjamin Peng from comment #197) > (In reply to Miks from comment #196) > > I found a way to replicate the freeze at least on my machine, the key beeing > > windows tooltips: > > 1. Open several Firefox tabs. > > 2. Move the mouse at the tab header of an inactive tab and at the very > > moment the tooltip appears, click the mouse to switch to that tab. You not > > always get the timing right, as you have to be very quick. > > > > In short: If tooltip is displayed at the same moment while the tab is > > getting activated, the tab freezes. > > WOW. Ingenious finding.. I can reproduce it. At the moment I am evaluating the possible fix of this edit: browser.chrome.toolbar_tips = false

(In reply to Miks from comment #199) > (In reply to Benjamin Peng from comment #197) > > (In reply to Miks from comment #196) > > > I found a way to replicate the freeze at least on my machine, the key beeing > > > windows tooltips: > > > 1. Open several Firefox tabs. > > > 2. Move the mouse at the tab header of an inactive tab and at the very > > > moment the tooltip appears, click the mouse to switch to that tab. You not > > > always get the timing right, as you have to be very quick. > > > > > > In short: If tooltip is displayed at the same moment while the tab is > > > getting activated, the tab freezes. > > > > WOW. Ingenious finding.. I can reproduce it. > > At the moment I am evaluating the possible fix of this edit: > browser.chrome.toolbar_tips = false I can still reproduce the problem with comment #196 in Firefox 37b7, even if I made the browser.chrome.toolbar_tips = false.

(In reply to Miks from comment #196) > I found a way to replicate the freeze at least on my machine, the key beeing > windows tooltips: > 1. Open several Firefox tabs. > 2. Move the mouse at the tab header of an inactive tab and at the very > moment the tooltip appears, click the mouse to switch to that tab. You not > always get the timing right, as you have to be very quick. > > In short: If tooltip is displayed at the same moment while the tab is > getting activated, the tab freezes. Nice work. I was also able to reproduce this bug quite easily with this method. It took maybe 10 or 15 tab switches for me.

If you guys can reproduce it really well, maybe we can finally get some answers. Does disabling desktop composition help? Disabling addons? Safe mode?

anonbugreport, can you reproduce the issue using the tooltip method?

On my system I had no issues with this (Win7 SP1 x64 + GTX770) until I upgraded to Fx36. Reverting to Fx35 and prior have no issues on this system. If I disable OMTC on Fx36, no issue. I first noticed it with the DownThemAll add-on, which temporary shows a notification bar on the bottom of the browser when you use dTA-OneClick, telling you how many items are queued. If you navigate to a new page when this bar is active, the notification bar and the entire browser page flashes black for almost a second. I can also reproduce it on the image gallery half-way down in this Ars article. Every couple times pressing the arrow or thumbnails to show the next image (scrolling animation), the entire gallery frame will flash black. http://arstechnica.com/gaming/2015/03/battlefield-hardline-single-player-impressions-forget-about-procedure/ I'm also starting to see the issue with parts of pages temporarily flashing black when I switch tabs. While it all sounds similar, are elements temporarily flashing black with OMTC the same issue as this bug? Or is this actually an unrelated OMTC regression in Fx36?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #203) > anonbugreport, can you reproduce the issue using the tooltip method? I can't. However I can't qualify for the requirement of being "very quick". A frame accurate action is beyond me. Another alternative to freezing Firefox is to try opening multiple images from the wikimedia page on Google Art Project and switching between them. Its not 100% reproducible for me but it occurs multiple times in a minute. https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project

To clarify. I could not reproduce the issue using the tooltip method in 36.0.4. I could reproduce the issue in a couple of minutes using the gigapixel images in 36.0.4. I could reproduce the issue with a clean profile though less frequently in 36.0.4. I could not reproduce the issue in the current try-build (fb557a9f924c) using any method or profile. There are a couple of freezes but they rarely last more than half a second and require no intervention to unfreeze. Is it be too late to apply the fix from fb557a9f924c to 37?

fb557a9f924c is very crash happy though.

(In reply to anonbugreport from comment #206) > To clarify. > I could not reproduce the issue using the tooltip method in 36.0.4. > I could reproduce the issue in a couple of minutes using the gigapixel > images in 36.0.4. > I could reproduce the issue with a clean profile though less frequently in > 36.0.4. > > I could not reproduce the issue in the current try-build (fb557a9f924c) > using any method or profile. > There are a couple of freezes but they rarely last more than half a second > and require no intervention to unfreeze. > > Is it be too late to apply the fix from fb557a9f924c to 37? Which images are you using? Most of those gigapixel images are too big to load in Firefox.

I've started a new build that adds some logging around the showing of tooltips. I'd be interested in getting a log from anyone who can reproduce it via tooltips using the build that shows up here https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-7ff9b169a0df

(In reply to Jeff Muizelaar [:jrmuizel] from comment #208) > (In reply to anonbugreport from comment #206) > > To clarify. > > I could not reproduce the issue using the tooltip method in 36.0.4. > > I could reproduce the issue in a couple of minutes using the gigapixel > > images in 36.0.4. > > I could reproduce the issue with a clean profile though less frequently in > > 36.0.4. > > > > I could not reproduce the issue in the current try-build (fb557a9f924c) > > using any method or profile. > > There are a couple of freezes but they rarely last more than half a second > > and require no intervention to unfreeze. > > > > Is it be too late to apply the fix from fb557a9f924c to 37? > > Which images are you using? Most of those gigapixel images are too big to > load in Firefox. It doesn't need to be that large, normally opening several tabs with resolution of 5000x5000+ images would cause noticeable lagging in UI operation (switching tabs, etc.)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #208) > Which images are you using? Most of those gigapixel images are too big to > load in Firefox. It doesn't need to be displayed. It fails to repaint very frequently if you switch between the images that are loading. However I doubt its related to the images directly as I have gotten the bug just by switching between 2 bugzilla tabs.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #209) > I've started a new build that adds some logging around the showing of > tooltips. I'd be interested in getting a log from anyone who can reproduce > it via tooltips using the build that shows up here > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-7ff9b169a0df I managed to reproduce with your build, but the log is scrolling so fast, that by the point i manage to focus on the command window several hundred lines have passed and the point at which the bug happened has long passed..

Ok i think i got it. I opened less tabs and manged to reproduce without the command window beeing spammed with liones, probably one of the tabs before was repeadiatly refreshing or something. Anyways. Here it is SetSize SetSize value: ff0009ff 8 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff0aff 9 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff000bff 10 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff0cff 11 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff000dff 12 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff0eff 13 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff000fff 14 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff10ff SetSize 15 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ff0011ff 16 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff12ff 17 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0013ff 18 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff14ff 19 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0015ff 20 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff16ff 21 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0017ff 22 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff18ff 23 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0019ff 24 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff1aff 25 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff001bff 26 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff1cff 27 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff001dff 28 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff1eff 29 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff001fff 30 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff20ff 31 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ff0021ff 32 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ffff22ff 33 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0023ff 34 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ffff24ff 35 EndFrame: Present(b3001c, 1200c2c8) 0 Show Click SetSize SetSize value: ff0025ff 36 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff26ff 37 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize >>> installPolicy shouldProcess() ... SetSize value: ff0027ff 38 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff28ff 39 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0029ff 40 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize SetSize value: ffff2aff 41 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff002bff 42 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff2cff 43 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff002dff 44 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff2eff 45 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff002fff 46 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff30ff 47 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0031ff 48 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff32ff 49 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0033ff 50 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff34ff 51 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0035ff 52 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff36ff 53 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0037ff 54 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff38ff 55 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0039ff 56 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff3aff 57 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff003bff 58 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff3cff 59 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff003dff 60 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff3eff 61 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff003fff 62 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff40ff 63 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff0041ff 64 EndFrame: Present(b3001c, 1200c2c8) 0 ShowTooltip SetSize SetSize Show value: ffff42ff 65 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0043ff 66 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff44ff 67 EndFrame: Present(b3001c, 1200c2c8) 0 Show SetSize SetSize value: ff0045ff 68 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff46ff 69 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0047ff 70 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ffff48ff 71 EndFrame: Present(b3001c, 1200c2c8) 0 Click SetSize SetSize SetSize value: ff0049ff 72 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ffff4aff 73 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff004bff 74 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff4cff 75 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff004dff 76 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff4eff 77 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff004fff 78 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ffff50ff 79 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0051ff 80 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff52ff 81 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff0053ff 82 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff54ff 83 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0055ff 84 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff56ff 85 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0057ff 86 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff58ff 87 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0059ff 88 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff5aff 89 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff005bff 90 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff5cff 91 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff005dff 92 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize ShowTooltip value: ffff5eff 93 EndFrame: Present(b3001c, 1200c2c8)SetSize 0 SetSize Show value: ff005fff 94 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff60ff 95 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff0061ff 96 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff62ff 97 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ff0063ff 98 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff64ff 99 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff0065ff 100 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff66ff 101 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0067ff 102 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff68ff 103 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize SetSize value: ff0069ff 104 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ffff6aff 105 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff006bff 106 EndFrame: Present(b3001c, 1200c2c8) 0 Click SetSize Show value: ffff6cff 107 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff006dff 108 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff6eff 109 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff006fff 110 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff70ff 111 EndFrame: Present(b3001c, 1200c2c8) 0 SetSize value: ff0071ff 112 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff72ff 113 EndFrame: Present(b3001c, 1200c2c8) 0 value: ff0073ff 114 EndFrame: Present(b3001c, 1200c2c8) 0 value: ffff74ff 115 EndFrame: Present(b3001c, 1200c2c8) 0 Click value: ff0075ff 116 EndFrame: Present(b3001c, 1200c2c8) 0 the last click and 2 lines after that, printed after the freeze when i clicked on the tab again to make sure im really frozen.

Anyways disabling DESKTOP COMPOSITION did NOT help. And the click who triggered the freeze in the log in my previous post should be the one which comes after 106

There will be a new build with more verbose logging that shows up here: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-ef66e791869f If you could try to reproduce the same thing again with this build that would be helpful.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #215) > There will be a new build with more verbose logging that shows up here: Jeff, it would be nice if you were posting links that are already working instead of links to something that will probably be available in the future. This would prevent people from the need to check whether the link is already live on their own, and therefore more people could participate in testing without wasting time. Thanks.

(In reply to Marat Tanalin | tanalin.com from comment #216) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #215) > > There will be a new build with more verbose logging that shows up here: > > Jeff, it would be nice if you were posting links that are already working > instead of links to something that will probably be available in the future. > This would prevent people from the need to check whether the link is already > live on their own, and therefore more people could participate in testing > without wasting time. Thanks. The build above had a problem. I'll post again when the replacement build that will show up here is done: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-854543f58dd8

The new build is up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-854543f58dd8/try-win32/

Tracking this for 39 and 40. Florin, do we have anyone on your team who can reproduce this? It sounds like we have made more headway on this and more testing on Jeff's new build(s) could help.

Disabling all plugins and addons, even the one dictionary i had, DID NOT help. So its purely firefox fault. I had trouble getting a useful log with the new build because the method which works the best for me. Opening several of the gigapixel images in https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project to load( they actually never finish loading, or show correctly but that doesnt matter you just have to open them in tabs so firefox tries to load them) floods the console withe hundreds of lines per second all the time making it impossible to get any useful log. I will try to trigger a freeze without loading the images.

i can repro this by opening 5-10 images in new tabs, viewing one and closing them one by one. image heavy pages cause it to happen more often too. as a temp work around i turned off HWA which seems to fix it.

Ok i got it ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ff004dff 2892 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ffff4eff 2893 EndFrame: Present(23fefcc, 11f27920) 0 value: ff004fff 2894 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff50ff 2895 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0051ff 2896 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff52ff 2897 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0053ff 2898 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff54ff 2899 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0055ff 2900 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff56ff 2901 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0057ff 2902 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 value: ffff58ff 2903 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0059ff 2904 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff5aff 2905 EndFrame: Present(23fefcc, 11f27920) 0 value: ff005bff 2906 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff5cff 2907 EndFrame: Present(23fefcc, 11f27920) 0 value: ff005dff 2908 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 value: ffff5eff 2909 EndFrame: Present(23fefcc, 11f27920) 0 value: ff005fff 2910 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff60ff 2911 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0061ff 2912 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff62ff 2913 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0063ff 2914 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 value: ffff64ff 2915 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0065ff 2916 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff66ff 2917 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0067ff 2918 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff68ff 2919 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 value: ff0069ff 2920 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff6aff 2921 EndFrame: Present(23fefcc, 11f27920) 0 value: ff006bff 2922 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff6cff 2923 EndFrame: Present(23fefcc, 11f27920) 0 value: ff006dff 2924 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff6eff 2925 EndFrame: Present(23fefcc, 11f27920) 0 value: ff006fff 2926 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ffff70ff 2927 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0071ff 2928 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff72ff 2929 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ff0073ff 2930 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff74ff 2931 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0075ff 2932 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff76ff 2933 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ff0077ff 2934 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ffff78ff 2935 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ff0079ff 2936 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff7aff 2937 EndFrame: Present(23fefcc, 11f27920) 0 value: ff007bff 2938 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff7cff 2939 EndFrame: Present(23fefcc, 11f27920)SetSize 0E910000, 316 173 0 value: ff007dff 2940 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff7eff 2941 EndFrame: Present(23fefcc, 11f27920) 0 value: ff007fff 2942 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff80ff 2943 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0081ff 2944 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff82ff 2945 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0083ff 2946 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ffff84ff 2947 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0085ff 2948 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff86ff 2949 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ff0087ff 2950 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff88ff 2951 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ff0089ff 2952 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff8aff 2953 EndFrame: Present(23fefcc, 11f27920) 0 value: ff008bff 2954 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ffff8cff 2955 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ff008dff 2956 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff8eff 2957 EndFrame: Present(23fefcc, 11f27920) 0 value: ff008fff 2958 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 value: ffff90ff 2959 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0091ff 2960 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff92ff 2961 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0093ff 2962 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff94ff 2963 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0095ff 2964 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff96ff 2965 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0097ff 2966 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ffff98ff 2967 EndFrame: Present(23fefcc, 11f27920) 0 value: ff0099ff 2968 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff9aff 2969 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ff009bff 2970 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ffff9cff 2971 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 value: ff009dff 2972 EndFrame: Present(23fefcc, 11f27920) 0 value: ffff9eff 2973 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ff009fff 2974 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ffffa0ff 2975 EndFrame: Present(23fefcc, 11f27920) 0 value: ff00a1ff 2976 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffa2ff 2977 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 value: ff00a3ff 2978 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffa4ff 2979 EndFrame: Present(23fefcc, 11f27920) 0 value: ff00a5ff 2980 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffa6ff 2981 EndFrame: Present(23fefcc, 11f27920) 0 value: ff00a7ff 2982 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffa8ff 2983 EndFrame: Present(23fefcc, 11f27920) 0 value: ff00a9ff 2984 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffaaff 2985 EndFrame: Present(23fefcc, 11f27920) 0 ShowTooltip SetSize 0BB71C00, 9 22 SetSize 0E910000, 316 173 Show 0BB71C00 2 1 value: ff00abff 2986 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffacff 2987 EndFrame: Present(23fefcc, 11f27920) 0 value: ff00adff 2988 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 SetSize 0E910000, 316 173 SetSize 0E910000, 316 173 Show 0BB71C00 2 0 value: ffffaeff 2989 EndFrame: Present(23fefcc, 11f27920) 0 SetSize 0E910000, 316 173 value: ff00afff 2990 EndFrame: Present(23fefcc, 11f27920) 0 value: ffffb0ff 2991 EndFrame: Present(23fefcc, 11f27920) 0 Click 0E910000 Click 0E910000 Click 0E910000 Click 0E910000 Show 0E910000 0 0 Show 0E220C00 4 0 last 4 clicks is me clicking on tab after the freeze. The click triggering the freeze should be the one at 2988. Last 2 lines printed when i alt-f4 the browser so it wouldn't suddenly decide to print a hundred lines while i try to copy the console.

I've worked today to reproduce this on Windows 7 x64 using Jeff's build from comment 218. I managed to get it to reproduce in about 50% of the cases, using the following scenario: 1. Open the build (firefox.exe -console) with a clean profile. 2. Go to https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project. 3. Middle click on the first 6 pictures to open them in new tabs (pictures will open on pages with a much smaller preview, so NOT at full size). 4. Start hovering a tab and then try to click on it in sync with the display of the tooltip. 5. Repeat step #4 for 1-2 minutes, then repeat the entire scenario with another clean profile if the issue does not reproduce. Results: in about 50% of the cases I can get into a state where I've clicked on a tab but it's not selected. I'm attaching two sets of logs: - try 1 - I got the issue at around line 406 - try 2 - I got the issue at around line 517

Florin, can you reproduce the issue on computers with different hardware?

I ma(In reply to Jeff Muizelaar [:jrmuizel] from comment #218) > The new build is up here: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla. > com-854543f58dd8/try-win32/ With this build, managed to reproduce the glitch, then I closed Firefox immediately (should I have done that?), and those were the latest lines printed: SetSize 18EAF800, 9 22 SetSize 0CC96C00, 316 126 Move 18EAF800, 714 92 Show 18EAF800 2 1 Click 0CC96C00 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 Show 18EAF800 2 0 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 ShowTooltip SetSize 18EAF800, 9 22 SetSize 0CC96C00, 316 126 Move 18EAF800, 634 96 Show 18EAF800 2 1 Show 18EAF800 2 0 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 Show 0CC96C00 0 1 Click 0CC96C00 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 SetSize 0CC96C00, 316 126 Show 0CC96C00 0 0 SetSize 0CC96C00, 316 132 Show 0B567000 4 0 I never got any line with "EndFrame: Present..." My graphics settings: Adapter Description Intel(R) G33/G31 Express Chipset Family Adapter Drivers igdumd64 igdumdx32 Adapter RAM Unknown Device ID 0x29c2 Direct2D Enabled Blocked for your graphics driver version. DirectWrite Enabled false (6.2.9200.16571) Driver Date 9-23-2009 Driver Version 8.15.10.1930 GPU #2 Active false GPU Accelerated Windows 0/1 Basic (OMTC) Blocked for your graphics driver version. Subsys ID 00000000 Vendor ID 0x8086 WebGL Renderer Blocked for your graphics driver version. windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

Well here is my graphics section if that is of any help. Adapter Description NVIDIA GeForce GTX 780 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM 3072 Asynchronous Pan/Zoom none ClearType Parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID 0x1004 Direct2D Enabled true DirectWrite Enabled true (6.2.9200.16571) Driver Date 3-13-2015 Driver Version 9.18.13.4788 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 00000000 Vendor ID 0x10de WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GTX 780 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

I take back what I said about the newer builds not freezing. It turns out the recording software I used to screen capture the console and Firefox simultaneously actually prevents Firefox from freezing.

I haven't been able to reproduce this locally yet. Does this build make it easier to reproduce? http://people.mozilla.org/~jmuizelaar/tab-switch/firefox-36-tooltip-sleep.zip It adds a sleep at the beginning of the process of showing the tooltip.

This build makes the whole browser microfreeze every 2-3 sec O_o Very noticeable when trying to scroll long pages or lists. Couldn't reproduce the original bug, although i spent only a few minutes trying.

@jrmuizel, if you need more people who can trigger OMTC issues there's a bunch at http://forums.mozillazine.org/viewtopic.php?f=23&t=2915159 (some of whom are probably already in this bug).

(In reply to Jeff Muizelaar [:jrmuizel] from comment #226) > Florin, can you reproduce the issue on computers with different hardware? I reproduced this in comment 223 on Windows 7 x64 with GPU: nVIDIA GeForce GT 610. I tried today on two other machines, the same scenario, but could not reproduce: - Windows 8 x64 + GPU: Intel HD 4400 - Windows 7 x64 + GPU: AMD Radeon HD 3000 (In reply to Jeff Muizelaar [:jrmuizel] from comment #231) > I haven't been able to reproduce this locally yet. Does this build make it > easier to reproduce? > http://people.mozilla.org/~jmuizelaar/tab-switch/firefox-36-tooltip-sleep.zip > > It adds a sleep at the beginning of the process of showing the tooltip. I tried this on the same Win 7 with nVIDIA machine where I reproduced the issue, but I could not reproduce the bug with this build (5 tries of the scenario from comment 223). I'd say this build does not in any way make it easier to reproduce the issue.

I can reproduce this in nightly usually once or twice a day. If you need someone to run a test build for a day or so, please ping me.

Can anyone reproduce this problem using the tooltip technique on non-Nvidia hardware?

I have mixed hardware multimonitor (GTX 760 currently 347.88; and Intel 4600 currently 10.18.10.3960) so I can test both with no other variations. The build from comment #223 is 404ing for me so I tried release ver 37.0.1. Was able to reproduce on Nvidia screen, but not Intel. Something about the nV driver hitting just the right timing to trigger a race condition I guess.

I meant build from comment #218 is 404ing. My bad.

On a hunch... I have been running with desktop composition disabled (Win7 x64) due to some issue with, I think it was OBS, I can't remember the details. Just to see, I turned it back on... I cannot reproduce the tooltip test with desktop composition enabled. To try to confirm this, I'm going to leave desktop composition on, and if/when I run into that issue again, I'll use compatibility flags to selectively disable composition. Let's see if the issue occurs under this configuration.

I've finally been able to reproduce the tooltip problem on a local nvidia machine :)

So the whole problem is only limited to nV GPUs, or just more frequently? It makes sense for me at least, I rarely encounter (don't remember if ever) this bug on my laptop which has an AMD GPU, but it's VERY frequent on my desktop (w/ GTX 660) so I have to turn off hardware acceleration to mitigate (not totally solve but much better) it.

I had this freezing issue for several version of Firefox with my AMD graphic card (HD 6850). But since Firefox 37, it happens often that the repainting is strange when I switch tab. It can be slow, the page is repainted by segments, but if I scroll down the page, it’s repainted instantly.