Closed Bug 434602 Opened 16 years ago Closed 16 years ago

After being open a few minutes, large parts of the screen don't repaint

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: asisser, Assigned: vlad)

References

Details

(Keywords: fixed1.9.0.6, fixed1.9.1)

Attachments

(8 files)

Screenshot of repaint problem (parts of two pages are displayed simultaneously)
108.93 KB, image/png
Details
Firefox does not refresh window
84.40 KB, image/gif
Details
FireFox 3 does not repaint correctly after resizing
56.95 KB, image/gif
Details
DC handle count when Firefox is just opened.
40.87 KB, image/png
Details
DC handle count after scrolling http://cersibon.blogspot.com/
40.39 KB, image/png
Details
Firefox redraw issues, with text, on linux
297.55 KB, image/jpeg
Details
fix, v1
2.74 KB, patch
pavlov
: review+
Details | Diff | Splinter Review
Port the trunk patch to 1.9.0
3.71 KB, patch
vlad
: review+
dveditz
: approval1.9.0.6+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 I wish I could provide a more detailed description, but the best I have is that after being open for several minutes, when I drag the firefox window around, parts of it stop repainting correctly. If I switch tabs, only the tab portion will repaint. If I push the window so that most of it is offscreen the drag it back on, the portions that are off will usually repaint. This even happens with pop-up windows like the Options dialog. I have dual screeds attached to a Matrox QID LP PCIe card - I assume this is related. I'm running XP Prop with SP2. Its the latest video driver last time I checked (v2.5.3.3 from 2/11/2008), works great with other apps, and worked flawlessly with the Mozilla 2.x I used to run, but has shown issues on all the 3.x betas and RC1. It doesn't appear to be related to dragging Firefox from one monitor to the other, and happens with the app on either one. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Flags: blocking-firefox3?
Just adding a comment that I experience this as well, with XP SP3 with an ATI X1400 mobility, so it's not matrox related. I've fairly certainly narrowed this down to integration with flash player (mine is 9.0 r115), since it's almost always when a flash applet appears that the browser's screen painting goes a little haywire. The best torture test is myspace; most myspace profiles are full of flash and completely break browsing. If a page isn't full of flash, scrolling up or down will usually repaint the page. I've noticed it tends to go back to normal after a while of browsing around, anywhere from a few pages to a few hundred. As stated, this has occured for all 3.x betas and the RC for me.
I also am running Flash 9.0 r115. I tried 9.0r124 and *so far* it seems to be ok. If it breaks, I'll add another comment.
Unfortunately, I still have issues with r124, but they have changed a bit. The problem is less frequent than it was before, and the screen fixes itself after scrolling down/up which wasn't always the case before. It also always corrects itself if I drag the window off screen, then back on.
Need a confirmation before we can consider blocking.
Flags: blocking-firefox3?
Are 2 users not confirmation? What else can I do to 'confirm' it?
I can confirm that I am getting this as well. There seem to be a number of repaint issues. I am using a dual-monitor setup, that may be a factor (although I seem to get problems regardless of which monitor I'm using at the time). I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 I can pretty consistently reproduce the problem from this page: http://www.getbluesky.org/bluesky/sti/ Clicking around to some of the graphics will pretty consistently cause problems, especially with the JavaScript animation. Sometimes scrolling up and down will help, other times not. I'm going to add a screenshot of the mangled page I get. I have also been able to reproduce this from a "safe mode" launch of Firefox.
Attached is a screenshot of the repaint problem I'm experiencing. One interesting thing is that the location bar is also not repainting correctly: the URL it shows is not valid (there should be more text after the word "graph")
OK, you can disregard my previous comments. Despite being able to consistently reproduce the problem yesterday, I can't reproduce it at all today. Possible reasons why the problem went away include: 1. The computer's been rebooted. (I can't recall for certain, but it's possible that I did not reboot between installing a QuickTime update and installing Firefox 3. Even though I was able to reproduce the problem on pages that didn't use the QuickTime plugin, it's very possible that a reboot fixed some magic in the plugin system.) 2. The webserver's been rebooted. (I can confirm this because I worked on the site in question.) 3. The images on the webserver have been regenerated by an automatic process. If an image rendering bug was to blame, re-creating the images may have resolved the problem. I'll try to reproduce the circumstances and post a testcase if I find anything. Otherwise, I guess I have to eat my words. Sorry for the bugspam.
I'm also seeing this in FF 3.0rc1. It appears to occasionally effect some .NET applications. Here is some information on my machine and graphics driver. OS: Win2K PC: Compaq Laptop nc6400 Graphics Driver: Intel Graphic Accelerator Driver for mobile Graphics Chipset: Intel(R) GMA 950 Intel(R) Graphics Media Accelerator Driver for Mobile Report Report Date: 05/29/2008 Report Time[hr:mm:ss]: 11:21:40 Driver Version: 6.14.10.4820 Operating System: Windows 2000* Professional, Service Pack 4 (5.0.2195) Default Language: English DirectX* Version: 9.0 Physical Memory: 1015 MB Minimum Graphics Memory: 8 MB Maximum Graphics Memory: 224 MB Graphics Memory in Use: 39 MB Processor: x86 family 6 Model 15 Stepping 6 Processor Speed: 1828 MHZ Vendor ID: 8086 Device ID: 27A2 Device Revision: 03 * Accelerator Information * Accelerator in Use: Mobile Intel(R) 945GM/GU Express Chipset Family Video BIOS: 1305 Current Graphics Mode: 2048 by 1536 True Color (60 Hz) * Devices Connected to the Graphics Accelerator * Active Notebook Displays: 1 * Notebook * Monitor Name: Plug and Play Monitor Display Type: Digital Gamma Value: 2.20 DDC2 Protocol: Supported Maximum Image Size: Horizontal: Not Available Vertical: Not Available Monitor Supported Modes: 1280 by 800 (60 Hz) Display Power Management Support: Standby Mode: Not Supported Suspend Mode: Not Supported Active Off Mode: Not Supported * SDVO Encoder Report * ** Encoder 1 ** Vendor ID: Chrontel Device ID: 60 Device Revision: 6 Major Version: 1 Minor Version: 1 * Other names and brands are the property of their respective owners.
I wish I had a more useful bug report, but I can't make it repeatable yet. However, I'm also having major repaint issues with RC1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0). My current session has 2 Firefox windows, with about 70 tabs between them. If I open a few more tabs, they will usually start being corrupted and not repainting. Switching between tabs at that point will not repaint unless I scroll. Animated GIFs will repaint themselves on the page though. The UI will also not repaint. Dragging the mouse over the UI causing the buttons to highlight will repaint them. I can the current page and UI to repaint if I drag a Firefox generated window, such as the Add-on or Options window around over the current browser window. Closing enough tabs will eventually restore the proper behavior. If I shrink the size of the window down, it will eventually get to a size where it will repaint itself. However, If I expand the window back, it will then show the repaint error. I don't know if this applies or not, but I did find reference to GDI objects in some of the other repaint bug reports. My current session has over 6700 GDI objects. This is on Windows XP, SP 2, with 3 GB RAM and a single 256 MB Video card, running two monitors.
I have the same problem ever since I installed FF3. After a few minutes, the window does not refresh properly. This behaviour is consistent but does not affect other programs. I'm using Win 2003 server on a T60 laptop. I have no other problems on this platform. I've tried Minefield 3.1a1pre to see if it was fixed. I'm attaching some screen shots. Ironically, the browser in the image is showign this very bug report page. I can run diag and post more information - just tell me what command to use.
Attached image Firefox does not refresh window —
The attached screen shot shows FF3 (3.1a1pre) trying to display a page. there are several tabs open. This is not an intermediate image - the screen does not change.
The attached screen shot shows FF3 (3.1a1pre) trying to display a page after a resize. there are several tabs open. This is not an intermediate image - the screen does not change.
I have a similar problem. After viewing a Youtube video in full screen, firefox stopped repainting properly. What I notice is that the repainting is fine as long as the FF window is smaller than approx. 1600x1200 but if I resize it to be bigger, the parts outside that region do not repaint. When I maximise the window, nothing repaints. In all cases buttons, links and so on repaint when I mouse over. I restarted FF with the saved session and it immediately had the same problem. I tried to make screenshots but somehow I only get black&white ones when I press print screen. I tried closing ~ 20 tabs but it did not help. I am running FF 3.0 release, 4 windows with overall 150tabs open. FF currently has 4177 GDI Objects. Windows 2003 Enterprise SP2 2 Screens, 1920x1440@32bit 4GB RAM, 2.5GB used, FF uses 450MB active FF addons: 404: File is not Found? Now it will be! Adblock Plus Adblock Plus ELement Hiding Helper Adblock Filterset.G updater Back To Top Colorful Tabs Configuration Mania Console² Customize Google Download Statusbar DownloadHelper Extended Statusbar Extension Manager Extended Firefox Showcase Fireshot Flashblock FloshGot Forecastfox Googlepedia Greasemonkey HTML Validator IE Tab Image Zoom Interclue Javascript Debugger Live HTTP headers MeasureIt PDF Download PlainText to Link Quick Java Rikaichan searchOnTab ServerSpy TabCounter TableTools TamperData TextLink UpdateNotifier WebDeveloper XPathChecker
Ah, I just realized this is the problem I'm having with Foxit Reader not repainting as well - my screen is 1920x1200, and above certain dimensions it stops painting. Same for firefox, after some testing, I think you nailed down the reason.
I'm able to reproduce this bug with a fresh profile with the release version of Firefox 3 and only the window for this bug report open. As others have mentioned, If I shrink the window small enough, it will repaint. For me, it seems to be tied to running the CAD software Pro/Engineer. If I have that fired up with a model on, I get the bug. If I quite Pro/E repaint will work fine. Firefox is the only application that has repaint issues when I have Pro/E open though. Again, this is on Windows XP SP 2, running two monitors off of a single Quadro FX 4000 card. I never had this problem running Firefox 2 on the same system. Unfortunately, this makes Firefox 3 near unusable.
I am having the same repaint issue with FF3 release and 3.0.1rc1 on WinXP SP3 with two monitors on an ATI graphics card. Clean reinstall of FF with no extensions and removing my previous profile makes no discernible difference.
A bit more information. I was able to resolve the issue by changing my main monitor from 32 bit to 16 bit color. I could leave the second monitor at 32 bit. Maybe this points to running low on video memory? Especially since it seems to affect people running two monitors off of one card which stretches video memory anyway. Also, this may explain why I had problems when I was running Pro/E as mentioned in Comment 16, a 3D CAD modeler will eat Video memory pretty quickly as well. I don't know why FF3 is so much more ungraceful in these situations then either FF2 was or why it doesn't affect any of the other apps that are running at the time though.
I can confirm comment 18. I have a Radeon X300 SE 128MB configured with two monitors at 1280x1024 at 32bpp. If I drop to 16bpp the problem goes away completely. Also, I can most reliably demonstrate the problem when Firefox is maximized or the window is otherwise larger than (about) 800x600, and when a page is open that contains large images. I can consistently reproduce with a page (http://www.getbluesky.org/bluesky/sti/graphanim.cfm?graph=pm25tot) that does JavaScript animation of large (bigger than about 800x600) images. (Potentially 72 frames at about 800x600; if stored uncompressed in 32bpp I think that's over 1GB of images.) It would seem that Firefox is trying to buffer many (all?) of the images referenced by a given page in video memory while the page is displayed, and that overflowing that memory causes the repaint problem described. I can also consistently reproduce with no other programs open but Firefox. (Background services and programs without GUIs excepted.)
Oops, excuse my bad math. 72 frames of 800x600 at 32 bits (4 bytes) per pixel equals about 132MB (sorry, I knew I had made a mistake somewhere in there). However, that's surprisingly close to the amount of video memory (128MB) that I have. That would seem to indicate that image decompression is using video memory and that saturating that up causes the repaint problem. If very large image decompression can corrupt video memory for the whole Firefox window, could (say) a carefully built PNG image cause an exploitable overflow? If so, this is a serious bug...
Just coming in to confirm that in my case the bug mostly appears a) when I have a second monitor online and b) when I have opened specific pages that link to a lot of bigger pictures (comparable to the 800x600 mentioned above). I have a video card with 512MB RAM, thus I wonder how it could be related to insufficient memory then. This even occurs when I have hardly anything else open besides FF3. Looking into the event viewer just after it happens, I have a lot of errors with NVCPL.DLL which is part of the nVidia driver stuff - it MUST have to do with the graphics adapter. Is prefetching enabled by default for Firefox? I can hardly believe everyone is having the same problems as we have. I have Fasterfox as an enhancement, prefetching is enabled there.
happens to me occasionally, seems to be related to large images or a large number of image files. Reproducible accessing http://cersibon.blogspot.com/ I also get a black screen with some white dots on Print Screen.
I can confirm reproducing the problem using the link in Comment #22. It happens even with both monitors at 16 bit.
Happens to me too. Standard browsing seems to make it trigger after a while (usually within tens of minutes) but hitting something made with gmaps or openlayers makes it trigger a lot faster. Examples: http://maps.google.com http://sigma.openplans.org/
I can replicate the problems reported by other posters: Firefox 3.0.1, Windows XP Professional patched and up to date, Dual-Monitor setup running on an nVidia Geforce 6600 running latest drivers. I have several plugins, but disabling them does not stop a recurrence of the issue. Firefox always functions as expected after a reboot, but within 10-20 minutes of use, it will stop redrawing properly. I associate the problem with viewing complex or graphic-intensive pages. Redrawing issues apply to both the browser's content and its controls. It means that effectively I am limited to a horizontal resolution of 800 pixels for Firefox, since otherwise it has to be 'tricked' to display the whole page (eg scrolling it off the display and back again, or selecting the content with the mouse) It seems to be a v3+ problem, since I ran the same setup with v2 without any issues for ages. It has reduced the utility of Firefox by an order of magnitude for me. I'm sorry that I don't have the skills or knowledge to fix this problem myself, but am happy to provide any information or assistance required to anybody who can help!
would someone please change the status to CONFIRMED? many test cases have been posted.
I also have this issue on dual monitor set up nVideo 9600GT. It seems to be related to dual monitors definitely. nVidia driver version 175.16 I can reliably reproduce this issue on my system by running Sun's NetBeans 6.1 IDE after running Firefox 3 for a few minutes. Once NetBeans is running the corruption occurs. It happens frequently after running Direct-X based games also. Doing a full reboot will fix the problem for a while but it eventually comes back. Please CONFIRM this bug. After years of using Firefox I'm considering switching browser until this is fixed.
I sympathize with comment #27, I've actually switched back to FF2 for the moment.
Hi Andrea, that's odd, but I more and more begin thinking of it, too. Does it help, actually?! CONFIRMING this bug would be a hell of niceness!
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
Flags: blocking1.8.1.17?
Flags: blocking-firefox3.1?
We need confirmation from a developer or QA before we can block on this. Marcia, can you take a look at this?
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
Flags: blocking1.8.1.17?
Flags: blocking-firefox3.1?
Keywords: qawanted
Whiteboard: need confirmation
Running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1, I am not able to see this issue as of yet. I visited the various sites referenced in the bug and waited some time, and yet I don't see the repainting issue that is posted in the screenshots. I am running XP on an IBM Laptop with ATI Mobility Radeon 7500 and my flash version is Shockwave Flash 10.0 b218.
There are lots of reports of this bug (or something closely related) here: http://support.mozilla.com/tiki-view_forum_thread.php?locale=nl&forumId=1&comments_threshold=0&comments_parentId=94940&comments_offset=0&comments_per_page=20&thread_style=commentStyle_plain I'm also experiencing a similar problem. Looking through the reports here and in support.mozilla.com (above link) there seems to be nothing obviously common except FF3.
Thanks for looking into this, Marcia. It seems to me that monitors and resolution are important to reproducing this bug. I've reproduced it on two different desktop systems (haven't tried a laptop yet) that both use dual-monitor configurations. I would suggest testing with the following configuration changes: 1. Make sure you're running in "True Color" (32bpp) mode 2. Use two independent monitors with resolution of at least 1024x768 each (preferably higher) 3. Increase the size of the Firefox window to fill at least one of the monitors completely I can provide additional details about my systems, if that is helpful. I am also running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1, and on at least two systems I can reproduce this problem 100% of the time.
Daniel: Thanks for the follow up. I tried reproducing this issue using my IBM laptop and an external Dell monitor and still no luck. I made sure that all three items you list in Comment 33 were invoked. The only thing that may be different in my case is the Flash version I am running. Can people who are seeing this bug try with the same version of flash I was running and see if the problem persists? You can get it from labs.adobe.com.
Dan, did you intend to add someone else? I'm not part of the QA team. :) (Haven't read the whole report; apologizes if I'm missing something!) Daniel Veditz <dveditz@cruzio.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djst@mozilla.com Keywords| |qawanted Status Whiteboard| |need confirmation
Just to follow up on Marcia's request: I upgraded to the new version of Flash and it did not have any effect. I highly doubt that Flash is an issue here, since I can easily reproduce the problem on pages that don't use any Flash elements at all. Actually, I'm pretty convinced that this has something to do with Cairo interacting with large GDI contexts. I can only reproduce when the Firefox window itself is larger than at least 800 to 1000 pixels square (but filling less than the available desktop space), depending on the specific video setup of the system. Both systems I've reproduced this problem with have Radeon chipsets, but lots of other people have reported issues using nVidia chips as well. Prior to Fx3.0, Cairo wasn't used to render <img> tag images (or JavaScript Image objects), right? It seems to me that the problem is pretty clearly tied to using excessively many and/or excessively large image elements in a large (> 1 megapixel) Cairo-rendered canvas.
Actually - I forgot to mention something similar - Once the corruption occurs, if I shrink the Firefox window from non-maximised state to a small size (e.g. 800x600) the corruption goes away. If the window is maximised again, then corruption comes back. It seems to be related to the size of the window and/or the size of the desktop (which would be much bigger with dual screen setup).
Aha! Thinking about desktops, and the number of pixels available on the desktop, led me to notice that both of the systems that I can reproduce this on are running MSVDM, the Microsoft Virtual Desktop Manager PowerToy from http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx . One of the configuration options for MSVDM is "Shared Desktops" -- that is, all windows are considered to be accessible from all desktops. Presumably this works by making all the virtual desktops part of a single GDI space or something like that. I tried turning this option off and now I can't reproduce the corruption on that system. I would be curious to see who else here that is experiencing this problem is running the MSVDM. Also, if you install/uninstall MSVDM, can you then reproduce/not reproduce the problem? I still think that this indicates a bug in Cairo, since other apps never seem to have an issue with the virtual desktops, but hopefully this points us in the right direction...
I'm not running MSVDM, but I am running "UltraMon" a similar utility.
I've seen this issue on both an ATI and an NVIDIA graphics card running two large monitors. Both manufacturer's drivers come with display management components, but otherwise neither system had desktop manager software installed.
I neither use MSVDM or any other desktop management tool, only thing that manages the desktops/resolutions is the 'in-built' nVidia control panel. I am changing screen resolution and activate the second monitor over the ususal Display Settings configuration. I thought that a skinning tool for Windows could have been the point. I am running Windowblinds which might have produced the corruption on my end. Unfortunately disabling Windowblinds did not help at all - an ugly desktop, but still redraw problems with GetBlueSky.org or any other site with huge graphics amount.
Oh hum, I don't have desktop management/sharing. One thing that I've seen in common with other reports is that the usage of Java based tools is triggering the failure. In fact I have Eclipse and some other java based apps (even Swing based) running all the day.
I am also not running MSVDM, but I am running nVidia's nView. I can only reproduced this when I am docked (2 1280x1024 displays), and if corruption occurred while docked, it carries over after I undock (1920x1200 built in display) until I restart Firefox. My co-worker can also reproduce on the same hardware: Dell Precision 6300 laptop running XP SP2 with a NVidia Quadro FX 1600M with a driver version of 6.14.11.5619.
OK, scratch my MSVDM comment: it works on one machine and not the other, so it may just be a fluke. Also, I don't think this is a Java thing: I happen to have Eclipse installed, but I can reproduce the problem without Eclipse running (these days I spend more time in Visual Studio anyway...) I'm going to reiterate that I think this is a Cairo bug. Judging from the comments, it seems that this mostly affects advanced users with demanding video needs -- perhaps that is a clue. Is there anyone here who understands Cairo enough to offer an opinion?
This morning it happened for me after playing a HD video using "MPlayer" (which I believe uses Direct X to render video). As soon as the video was playing, the Firefox page tabs stopped rendering.
I also have this issue at work. I run 2 screens with firefox 3. I tried updating graphics drivers and it doesn't help. It usually happens when I'm doing a lot on the computer, doing CAD and Excel, etc. Not only does Firefox start displaying pages incorrectly, but the computer as a whole does not repaint correctly. The desktop does this, and so does Acrobat Reader. Snagit gives a "cannot capture input" error when i try and take a screenshot. I really like firefox, but this bug makes it difficult to use with 2 monitors because I have to restart all the time.
I would like to pretty much echo #46. WinXP, 2 displays, FF3, NVIDIA Quadro FX 3700 card, 4GB memory. I also run into the SnagIt "cannot capture input," and additionally the built-in print screen display capture also stops working at this point (when FF3 stops drawing itself correctly). My work-around is to drag FF3 off screen and back on, but the issue of not being able to capture any display input by any means (with SnagIt or print screen) cannot be resolved without rebooting. This is an extremely-super-mega annoying issue, and is becoming a borderline dealbreaker for me. I'm almost at the point where I switch back to Internet Exploder. Ugh.
At Marcia's suggestion (#34) I upgraded to the latest Flash 10 beta. About:Plugins identifies it as 10.0.2 d26, which is not the same as the one she identified in #31, but I guess I'm a bit slow and it has incremented. However, this did not alleviate the problem. The repaint problem also manifests itself in plugin-free Safe Mode, which surely should rule out Flash as the culprit?
Windows XP Pro, nVidia GeForce Go 7800, 2GB RAM, same problem. Absolutely maddening issue, I tried every single thing suggested here, none work. How do we get this actually assigned to someone to investigate, and make the status confirmed? It disappoints me a bit to think that after I've had everyone I know switch to FireFox, I find a brick wall in usability like this.
Btw, I can confirm that when the problem starts occurring screen snapshot cannot be taken anymore with SnagIt, IrfanView or the simple print screen windows shortcuts. Oh, btw, it seems everybody here is on XP Pro (probably SP3) with the exception of one on Win2000? Like, I don't see anybody using Vista reporting the issue?
Andrea (#50), I run FF3 and Vista Ultimate at home with 2 monitors cranked all the way up and I have never seen this issue.
Yep, I can confirm that I am on a Windows XP SP3 machine. Too bad there is noone willing to concentrate on solving this issue officially.
Don't know it it useful or relevant, but when Firefox stops redrawing successfully, the Peazip archive utility I have installed (http://peazip.sourceforge.net/) also often seems to misbehave in a similar fashion.
I can report that having only one monitor active, our beloved testing pages for the bug fail to produce the bug itself - it seems it almost must have something to do with a dual monitor setup.
The signal-to-noise ratio on this bug is getting pretty low, I think partly because the exact cause of the bug is so elusive. Here's an attempt to clarify the exact issues: - The bug is that Firefox has repaint issues under certain circumstances. These are demonstrated clearly in the screenshots attached to the bug. - The regression window is sometime between Firefox 2 and Firefox 3; since Firefox 3 is the first release from trunk in some time, it's possible that this bug could have been dormant on the trunk for some time before that. - Some users can reliably reproduce the problem, for others it is intermittent. - Among users who can reliably reproduce the problem, high graphics demand (large monitors, multiple monitors, high color depths, lots of video or Flash, lots of images, etc.) seem to make the problem more likely to occur. - Among users who can reliably reproduce the problem, it nearly universally occurs when the Firefox window itself is larger than 800x600; on some systems the Firefox window must be 1280x1024 or larger to begin to see repaint issues. - When repaint issues occur, they affect both chrome and content. - Some users report that when the bug occurs, video corruption affects other programs. Other users report no such effects. - Some users report being unable to capture screenshots. Other users have captured screenshots and added them to this bug. - Some users have speculated on a correlation between this bug and running certain other applications (generally graphics-intensive or memory-intensive programs). - Users reporting this bug almost universally are using Windows XP. Insufficient evidence exists to reliably confirm or deny that other platforms are affected, but the number of vocal users complaining about Windows XP implies that it is at least most strongly affected. - For some reason, it seems this bug is more likely to affect "power users" and other advanced users, rather than technology neophytes. Given the inconsistency of reports, I'm beginning to wonder if there may actually be more than one bug here. Specifically, since several people have indicated issues with capturing screenshots or video corruption affecting other programs, perhaps those issues should be split out as a separate bug. From where I stand, the next steps appear to be: 1. Someone who can reliably reproduce the problem should try to narrow the regression window. 2. A developer who understands the graphics subsystem should investigate the code for possible causes. 3. Someone with some authority should decide whether we need to split into two bugs. I can volunteer to assist with either of the first two, but my knowledge of Cairo and the Firefox source tree is limited (I have compiled from source before, but not in a while, and I'm not set up to build it on Windows right now). I can also volunteer to work on the regression window, but I'm not familiar enough with the process to know the right way to go about doing it. I'll browse around and try to find some info. At this point, between this bug and the support forums, I think we have enough anecdotal evidence. Unless you have something to add that doesn't fall under the existing points I've listed, you should probably just add a comment over at the support forum page instead of on this bug. Any thoughts?
This bug is completely reproducible on my Windows 2000 SP4 system. Presence of any Flash content is not necessary - the graphics corruption occurs on any image-heavy page, or if enough tabs are open each with a few (or even one) image. Resizing the Firefox window below a certain size will usually restore functionality, except that if the corruption gets very bad only closing & restarting Firefox will restore it. This system uses six (yes, 6!) displays: 4 connected to a Matrox G450MMS (1 landscape [at 1280x1024], 3 portrait [1 at 1024x1280, 2 spanned into a single 2048x1024 display]); 2 connected to an nVidia 6600 (1 1280x1024 display; 1 1920x1080 display).
I'm seeing this bug 100% of the time after using FF3.01 (release) on both my home and work systems: HOME: HP laptop, WInxp SP3, 2GB RAM, FF3.01, Single monitor driven by it at 1280x1024 WORK: HP Laptop, Vista SP1, 2GB RAM, FF3.01, Dual monitors driven at 1200x900 (if I remember right) and 1650x1050 Seems to happen faster if I use FF extremely actively, like going from page to page in Flickr viewing photos. If I do that, it repro's in about 5-7 minutes. I can close FF and restart it and when I do FF throws and error that the application is launched but not responding. I manually kill the process, the restart it and all then works (for another 5-20 minutes) This is my absolute Number ONE firefox bug. It makes me have to keep IE around for extended photo browsing.
Finally took the plunge and moved to FF 3.0.1 from my relatively stable FF 2.0.0.16 installation. Seeing this very aggravating problem consistently on my laptop which drives (2) 1680x1050 displays when docked. Happens after about 20 minutes of use - doesn't even have to be active use of FF, if I'm using another app like Outlook 2007, when I come back to FF it stops repainting. If I run the cursor with the mouse button held down, portions of the screen will repaint, frequently inaccurately. I've seen ghosting of a page on the previous tab when switching tabs. If I minimize the browser and restore it, I'll either have the same glitched ghosting or just title bars and my desktop background image ghosted through. This is happening on a Dell Precision 4300 with a Quadro FX 360M with 512MB RAM, running nVidia ForceWare version 101.19 on Windows XP SP2 with 4GB of system RAM. In other words, a fairly stout configuration to be having display issues. Oh, and level of graphics on a given web page seem to make no difference, as I've seen the browser start ghosting and/or not repainting just sitting on the Google homepage. moving back to FF2 for now, which only exhibited this problem on rare occasions when running very graphically intensive stuff (CAD applications).
... I switched from windows classic style to windows xp style and the issue hasnt been reproducible yet (it was consistently reproducible before). Can someone else who has the problem try this and see if I am insane?
(In reply to comment #59) Well, you're probably not insane, but I think you're looking at a red herring. I've been running with the Windows XP style the whole time, so I doubt that's the issue. I even tried switching back to the Classic style, and it had no effect.
(In reply to comment #60) > (In reply to comment #59) > Well, you're probably not insane, but I think you're looking at a red herring. > I've been running with the Windows XP style the whole time, so I doubt that's > the issue. I even tried switching back to the Classic style, and it had no > effect. You are absolutely right, after about 4 hours of usage its back.
My computer is giving this error right now. Is there some kind of information I can get off of it to pinpoint this problem?
Running on WinXP SP2 on Dell. Using 1920x1200 dual monitors driven by a single nVidia Quadro FX 3500. Saw this problem readily following install of FF3. It usually didn't take long to make it happen. Perhaps some correlation with the number or type of other apps running but can't be sure on that. Updated my display driver to the latest available from Dell and the problem went away. At least, under similar conditions and over 1 week of usage, I have not seen a recurrence of the problem so far. Previously the problem would usually happen within 1 day or less.
Happens to me too. WinXP SP2,dual monitor setup on Compaq 6710b. Resolutions: 1280x1024 and 1680x1050. Happens right away, when going to http://cersibon.blogspot.com/. I am web developer and do a lot of web pages refreshes. This bug makes Firefox 3 unusable. I am thinking about Google Chrome. Viktar
I confirm this bug. Going to http://cersibon.blogspot.com/ reproduces it. WinXP SP2, NVIDIA Quadro FX560M, resoultion 5120x1024x32, 4 displays. Note: when Firefox stops repainting correctly and I have Visual Studio 2005 (VS) instances running, if I close one or more VS that cures the problem and Firefox starts to repaint itself correctly (no need to restart it). Adobe Reader seems to have the same problem and is also cured by closing VS. Firefox 2 on the same machine never had this problem. Max
If I go to http://cersibon.blogspot.com/ and scroll the page up and down dragging the slider using the mouse, the GDI handle count only ever grows (as shown in Process Explorer by Sysinternals). When the page is closed the handle count does not go down either. I downloaded "GDIView v1.03 - View GDI handles/resources list and detect GDI leak" from http://www.nirsoft.net/utils/gdi_handles.html It shows that when I scroll that page the DC handle count grows to more than 1000, which is quite a lot (no other application on my system uses more that 100 DC handles at a time). These handles do not seem to be cleaned up when the page is closed. It looks to be a GDI handle leak to me. Please see attached screenshot named "DC handle count ..." Max
It also seems to have something to do with the size of the firefox window. If i make it smaller it has an easier time repainting. If I make it large, especially full screen, it has issues.
I confirm this bug, along with at least 3 other people here at work. WinXP SP2, NVIDIA Quadro FX3500 256MB Driver version 6.14.11.6996, 2 screens at 1600x1200 resolution. For me it is worse when Lotus Notes is running (version 7 client). I can also confirm that shrinking the window fixes the repaint issue regardless of how many tabs I have open. Firefox 2 on this machine runs just fine.
(In reply to comment #68) > If I go to http://cersibon.blogspot.com/ and scroll the page up and down > dragging the slider using the mouse, the GDI handle count only ever grows (as > shown in Process Explorer by Sysinternals). When the page is closed the handle > count does not go down either. > > I downloaded "GDIView v1.03 - View GDI handles/resources list and detect GDI > leak" from http://www.nirsoft.net/utils/gdi_handles.html It shows that when I > scroll that page the DC handle count grows to more than 1000, which is quite a > lot (no other application on my system uses more that 100 DC handles at a > time). These handles do not seem to be cleaned up when the page is closed. > > It looks to be a GDI handle leak to me. > > Please see attached screenshot named "DC handle count ..." > > Max I can confirm that I went to that site with a working firefox instance scrolled up and down while watching the GDI count in firefox. It got to well over 3000 GDI object then maximized the window and it caused the repaint issue. After killing firefox and bringing it back up repaint issue was gone.
I just tried to see how high I could make the GDI Object count grow by following the steps in step #68 and it seems to be capping at 10,000 GDI objects. At which point it even has problems repainting the images during the scroll and you can no longer resize firefox small to get a repaint. All window sizes demonstrate the issue. I then closed the tab to see if any of those GDI objects would be reclaimed after 10 minutes GDI count is at 9996.
Just so everyone knows you do not need a special tool to view GDI object count. If you bring up the Windows Task Manager and select View->Select Columns. There is a check box to show GDI Object count. So if others could confirm that repeatedly scrolling on the webpage in comment #68 caused the GDI count to grow that would be great.
1. You need to open Task Manager and swith to "Processes" tab first in order to be able to view GDI objects if you wonder where that option is. 2. Being on a single screen this time, I get around 1.500 GDI objects for/from Firefox, not growing when scrolling the page from #68. Closing the specicif tab does not change the number of GDI objects then. No repaint issues though.
I opened the task manager and tried to recreate this. I went to the website mentioned earlier and scrolled up and down a bunch and this error recreated itself when the GDI got to about 1000. I kept scrolling and the GDI kept increasing, and I stopped about 2650. Next, I shut of my second monitor in the display properties panel. On just one monitor, the GDI is still about 2650 but firefox repaints correctly. On a program note: SnagIt 7 is still unable to capture input. I also use Lotus Notes 7, as mentioned earlier.
Sorry.. one more. While on the single monitor, even though Firefox repaints correctly, I still see tracers of programs over the desktop background and I have to "wipe" these off with a program window.
A bit of curio: I was also unable to capture input with SnagIt v7 after this condition began. However, with v8 of SnagIt, this issue has been resolved. I found mention of this issue in TechSmith's (developer of SnagIt) user forum here: http://forums.techsmith.com/showthread.php?t=1270 The user who discovered the issue was using XP with multiple monitors and an nVidia graphics card. Perhaps these issues are somehow related.
I'm experiencing similar redraw issues: On Linux. This is odd. Scrolling the page seems to cause problems, only above a certain resolution, and only when video-memory-consuming apps are open in the background (eve online). Dragging and releasing an image, selecting another window, or moving the firefox window seems to fix the issue. Selecting all (ctrl+a) and then deselecting also seems to work. It only affects the content, not firefox itself, but I normallly run maximized. Also, since moving the window fixes it (I think Plasma forces a redraw?) I can't tell if it would corrupt the window itself. Kubuntu-KDE4, hardy backports, Nvidia-GLX-New, Nvidia Geforce 7900GT. Firefox 3.0.1. The question then is, is this related? I don't see any similar FF redraw bugs, so I'm guessing it is. Extensions, just in case, though the above makes it seem extension independent: 4chan Adblock Plus All-In-One Sidebar DownloadThemAll! FireGestures FlashGot FoxyProxy Gmail Manager ImageZoom LeetKey MR Tech Toolkit NoScript PDF Download RSS Ticker Session Manager Stylish Tree Style Tab Update Notifier VeriSign's OpenID SeatBelt YouTube Comment Snob
I see this 100% after about 10-15 minutes on both my work machine (notebook driving external monitor - hence 2 displays) and on my home machine Notebook driving a SINGLE external display. Therefore it is not unique to those with dual displays. In both my cases, I'm driving my display from a Laptop/Notebook computer. Both probably have mid to low level graphics capability. I'm implying that systems with wimpier graphics horsepower might repro this more easily. ALSO: I noticed that shrinking the window to 800x600px can cause the repaint issue to go away, but it usually comes back 1-2 minutes later, and I have to shrink the window more... then 2 min later, even more. Within 5 minutes, I can only get the screen to draw correctly with an unusably small 300-400px window!
Hrm. For those of you who can reliably reproduce it, can you do a test for me? Quit Firefox, and open up a command prompt (cmd.exe). Type: set MOZ_DISABLE_IMAGE_OPTIMIZE=1 "C:\Program Files\Mozilla Firefox\firefox.exe" (or whever you have firefox installed, but make sure you start it from the command line) Try to reproduce it then, ideally watching GDI usage along the way.
Setting the (In reply to comment #80) > Hrm. For those of you who can reliably reproduce it, can you do a test for me? I am the one reliably suffering from this problem. > Quit Firefox, and open up a command prompt (cmd.exe). Type: > > set MOZ_DISABLE_IMAGE_OPTIMIZE=1 > "C:\Program Files\Mozilla Firefox\firefox.exe" Setting the environment variable solves the problem. http://cersibon.blogspot.com/ does not cause any redrawing issues any more. > Try to reproduce it then, ideally watching GDI usage along the way. The GDI handle count now reaches a certain number and does not grow any more when scrolling that page. In other words, setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 seems to fix the GDI handle leak. Max
Max, thanks! Ok, so looks like my attempts to fix the resource contention with GDI weren't fully successful. There's no way to ask how much video ram is remaining to decide when to stop trying to optimize images and put them on the video card, which is unfortunate. For the GDI objects, we do use a good chunk, but I'm pretty sure that we don't actually leak any of them... they just get held on to in caches that should have timers shorter than what you're seeing though, so there's possibly still a bug there. Gonna look into it.
Assignee: nobody → vladimir
Status: UNCONFIRMED → NEW
Component: General → GFX: Thebes
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes
Whiteboard: need confirmation
Flags: blocking1.9.1+
Priority: -- → P1
Thanks, Vlad, for looking into this. As someone else who has been able to reliably reproduce the problem, I'm able to confirm that setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 solves the issue, at least on one of my computers (haven't tested others yet). For the record, I've been seeing display corruption even when the GDI handle count isn't extremely large (I've seen Visual Studio grab 3x as many GDI handles as Firefox on a bad day). But I've generally been testing with pages that have larger, high-resolution images, so it's likely that a smaller number of images will fill up video RAM. (I think that's what you were referring to in your comment.) Regarding timing: I had been about to post a comment that my hunch was a GC timing issue, since I was definitely seeing the behavior that handles would build up and then drop off all at once. If there is a timer for when the GDI objects get released, could there possibly be a race condition when a page is continuing to load images (e.g. while the page is still loading or if JS is changing images)? Those cases seem to be the most reliable way of reproducing the problem on my systems.
Thanks Max and Vlad, MOZ_DISABLE_IMAGE_OPTIMIZE=1, solves my issues. Will test in long run, since repaint problem sometimes appears from nowhere (no big images, no scrolling or resizing). May be because of Visual Studio, which is always on. Viktar
Yep, there are two limits -- a global GDI object limit and a video ram limit. The latter isn't as easy to query/avoid. Ideally, we would just stop using GDI objects except where we must (fonts, in particular), but performance could be an issue -- are you guys seeing any performance issues with MOZ_DISABLE_IMAGE_OPTIMIZE?
Thanks guys, I FireFox 2 felt like being in the stone age while I waited for this to be fixed.
Thanks Vlad and Max, I am currently forced to run FireFox 2 right now as well because this issue has made it impossible to use 3. Do you need any further validation done? I can re-install FF 3 and test for a period if required.
Tried the proposed solution on a freshly reinstalled FF 3.0.1, no go, it still does not repaint properly if the window is bigger than approximately 800x600. I've tried both "set MOZ_DISABLE_IMAGE_OPTIMIZE=1" on the command line and then starting from the same console, and by setting the same variable in the system enviroment, same result. And oh, I'm on XP, dual screen (screens are not the same resolution btw), ATI card.
(In reply to comment #82) > Max, thanks! Ok, so looks like my attempts to fix the resource contention with > GDI weren't fully successful. There's no way to ask how much video ram is > remaining to decide when to stop trying to optimize images and put them on the > video card, which is unfortunate. For the GDI objects, we do use a good chunk, > but I'm pretty sure that we don't actually leak any of them... they just get > held on to in caches that should have timers shorter than what you're seeing > though, so there's possibly still a bug there. Gonna look into it. Although with MOZ_DISABLE_IMAGE_OPTIMIZE=1 Firefox does not seem to have problems displaying http://cersibon.blogspot.com/, it still occasionally has problems redrawing :(. It happens when there are one or more instances of Visual Studio 2005 running at the same time. Most of the time, but not all the time, closing Visual Studio's makes Firefox redraw correctly. Adobe Reader seems to have the very same problem redrawing and is also fixed by closing Visual Studio's. Vlad, you mentioned before that there is some system wide GDI handle limit. May it be that Firefox creates GDI handles above that limit? Max
Max - that's not too surprising, since Visual Studio is a huge GDI handle hog. I've seen it create 1000+ handles just by opening, before you even open a project. If you're just using a lot of GDI objects, you may need to tune your per-process GDI handle limit and/or the session paged pool size. I found this article, which is oriented toward Terminal Services, but it may apply here (I'm frankly not sure): http://support.microsoft.com/kb/840342 Also see: http://msdn.microsoft.com/en-us/library/ms724291.aspx The other culprit might be the desktop heap: http://support.microsoft.com/kb/126962 Vlad - Regarding performance issues, MOZ_DISABLE_IMAGE_OPTIMIZE does introduce some mild "stuttering" in e.g. animated GIFs sometimes. But I haven't seen performance issues that I would complain about otherwise. YMMV, of course.
I've been reading for a while, and I'm wondering this: Are we suggesting that this is a whole machine/software problem rather than a firefox 3 problem?
(In reply to comment #89) > (In reply to comment #82) > > Max, thanks! Ok, so looks like my attempts to fix the resource contention with > > GDI weren't fully successful. There's no way to ask how much video ram is > > remaining to decide when to stop trying to optimize images and put them on the > > video card, which is unfortunate. For the GDI objects, we do use a good chunk, > > but I'm pretty sure that we don't actually leak any of them... they just get > > held on to in caches that should have timers shorter than what you're seeing > > though, so there's possibly still a bug there. Gonna look into it. > > Although with MOZ_DISABLE_IMAGE_OPTIMIZE=1 Firefox does not seem to have > problems displaying http://cersibon.blogspot.com/, it still occasionally has > problems redrawing :(. Whole day today Firefox did not have any redrawing issues with MOZ_DISABLE_IMAGE_OPTIMIZE=1 after I logged off and back on. I still hope it solves the problem. I will be keeping an eye on it and keep you guys informed. Max
(In reply to comment #91) > I've been reading for a while, and I'm wondering this: Are we suggesting that > this is a whole machine/software problem rather than a firefox 3 problem? Well, it's not directly a Firefox problem per se, but it's caused by both Firefox and other apps on the machine using large numbers of GDI handles. We can do a bunch of work on the Firefox end to reduce our GDI usage to make us less susceptible to the problem. But the core issue is just overall high GDI object use on a given system, hitting the windows GDI global object limit.
(In reply to comment #93) > (In reply to comment #91) > > I've been reading for a while, and I'm wondering this: Are we suggesting that > > this is a whole machine/software problem rather than a firefox 3 problem? > > Well, it's not directly a Firefox problem per se, but it's caused by both > Firefox and other apps on the machine using large numbers of GDI handles. We > can do a bunch of work on the Firefox end to reduce our GDI usage to make us > less susceptible to the problem. But the core issue is just overall high GDI > object use on a given system, hitting the windows GDI global object limit. If this is the case why did quickly scrolling on #68 cause 9999 GDI objects to spawn and only decrease to 9996 after a few minutes. After several hours the GDI count was still 9996. Unless windows task manager is lying which is very possible it would seem there are leaks.
(In reply to comment #93) > (In reply to comment #91) > > I've been reading for a while, and I'm wondering this: Are we suggesting that > > this is a whole machine/software problem rather than a firefox 3 problem? > > Well, it's not directly a Firefox problem per se, but it's caused by both > Firefox and other apps on the machine using large numbers of GDI handles. We > can do a bunch of work on the Firefox end to reduce our GDI usage to make us > less susceptible to the problem. But the core issue is just overall high GDI > object use on a given system, hitting the windows GDI global object limit. Well, I'd suggest it's a FF problem when neither IE7, Safari, Chrome or even FF2.0 exhibit the problem. Looking forward to a formal fix. Go team!
(In reply to comment #89) > Although with MOZ_DISABLE_IMAGE_OPTIMIZE=1 Firefox does not seem to have > problems displaying http://cersibon.blogspot.com/, it still occasionally has > problems redrawing :(. So I'm having problems reproducing with this site -- when I start firefox, my GDI handle count (according to task manager) is around 100; opening this site makes it go up to about 280, but no higher, no matter how much I scroll around. I have two copies of visual studio open as well, each one of them is using ~1000 gdi handles. Are there any other sites that people are seeing this problem on? Ideally I need a way to reproduce this, otherwise it's going to be a pain to fix :(
Run the browser full screen and it will show up faster. Open google maps and zoom around. It goes nuts for me.
It is a week since I put MOZ_DISABLE_IMAGE_OPTIMIZE=1 in enviroment settings. I didn't see any problems since then. I can browse google map, http://cersibon.blogspot.com/, nothing. Are you trying to reproduce problem with MOZ_DISABLE_IMAGE_OPTIMIZE=1 set on? Do you have two monitors? (In reply to comment #96) > (In reply to comment #89) > > Although with MOZ_DISABLE_IMAGE_OPTIMIZE=1 Firefox does not seem to have > > problems displaying http://cersibon.blogspot.com/, it still occasionally has > > problems redrawing :(. > So I'm having problems reproducing with this site -- when I start firefox, my > GDI handle count (according to task manager) is around 100; opening this site > makes it go up to about 280, but no higher, no matter how much I scroll around. > I have two copies of visual studio open as well, each one of them is using > ~1000 gdi handles. > Are there any other sites that people are seeing this problem on? Ideally I > need a way to reproduce this, otherwise it's going to be a pain to fix :(
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.4?
Attached patch fix, v1 — — Splinter Review
We're using a DDB for double buffering for paint, but we weren't properly handling the case where a DDB wasn't available (due to video memory pressure). In Firefox 2, we'd fall back to a DIB in this case, so let's make the same thing happen in cairo's create_similar().
Attachment #341165 - Flags: review?(pavlov)
Attachment #341165 - Flags: review?(pavlov) → review+
I fear it will not help any further to solve this bug, but notionless as I am, I am asking you: does the .patch file mean that this a) cannot be applied to a normal FF3 installation on win32 and b) will hopefully be included into the next FF3 update, possibly 3.0.4, then? Does this fix suggest that this is less a temporary and more a permanent fix for the thing? Thanks in advance!
(In reply to comment #100) ratzekind: I'm not sure I understand your question... are you saying you don't understand what .patch files are for? Perhaps you could Google around for some enlightenment. Once the patch has passed senior review and been approved then the fix will show up in the next Firefox update. In the meantime, you can test the the fix by recompiling Firefox. If you don't know how to do that or don't want to compile Firefox yourself, then you should probably just wait. As for "more a permanent fix", I think the comment says it well: /* Note that if an app actually does hit this out of memory * condition, it's going to have lots of other issues, as * video memory is probably exhausted. */ The patch makes Firefox better able to handle the case when video memory is nearly saturated, but problems may still persist, since the point of the problem is that you're nearly out of video memory.
Hey Daniel, thanks for your kind answer. That is exactly what I was asking for - I am now aware that I had better wait for the fix to be implemented into a new update of Firefox. All is fine then, good to see a fix crawling in;-).
After updating to 3.0.3 the MOZ_DISABLE_IMAGE_OPTIMIZE=1 work-around is no longer working for me. My GDI count for firefox.exe hits > 1000 within minutes and never comes down, even when closing all tabs. I'm back to the old "solution" of resizing the window down to roughly 800x600. Also if it's of any interest, things like iTunes and AIM are using > 2000 GDI objects without any redraw issue.
(In reply to comment #99) > Created an attachment (id=341165) [details] > fix, v1 > > We're using a DDB for double buffering for paint, but we weren't properly > handling the case where a DDB wasn't available (due to video memory pressure). > In Firefox 2, we'd fall back to a DIB in this case, so let's make the same > thing happen in cairo's create_similar(). What about issue where rapid scrolling on the url from comment #68 caused the GDI object count to rise above 9000 (teetering around 9999) and after closing all tabs and leaving firefox there for 5 hours the GDI Object count never decreased below 9996? Is this a seperate issue that a new bug should be filed for? As it seems this bug is heading in the direction of a fix that checks for the max GDI object count and falls back rather than research GDI object leaks.
(In reply to comment #103) > After updating to 3.0.3 the MOZ_DISABLE_IMAGE_OPTIMIZE=1 work-around is no > longer working for me. My GDI count for firefox.exe hits > 1000 within minutes > and never comes down, even when closing all tabs. I'm back to the old > "solution" of resizing the window down to roughly 800x600. > > Also if it's of any interest, things like iTunes and AIM are using > 2000 GDI > objects without any redraw issue. I can confirm this. The behavior is not as rampant but after using MOZ_DISABLE_IMAGE_OPTIMIZE since the original suggestion was made I have seen the problem resurface.
Flags: blocking1.9.0.4?
I checked a fix for this in; it'll appear in tomorrow's nightly build, available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk (but only tomorrow, today's wont have the patch in). If those of you who could reliably reproduce this could try a nightly build and let me know if it fixes the problem, that'd be much appreciated. Once it's verified, then we can look at getting it in to 3.0.x.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
MOZ_DISABLE_IMAGE_OPTIMIZE doesn't work 100%. Somethimes I still see problems, but not as often as used to be. Usually it happens when I have two Visual Studio open. I installed nightly build. So far no problems. I opened two Visual Studio,two Minefields each with dozen Blue Skyes. Nothing. Looks like problem is solved. I'll continue to us Minefield and let you know if I see any problems.
I also installed minefield 3.1b2pre. I've been running it for about an hour with no problems. I went to the http://cersibon.blogspot.com/ website and scrolled around and also used google maps with no issues. I can get the GDI count to go up over 1000 when using google maps & satellite images, but it knocks the count back down as I move around and way down when I close the tab.
I've been running 3.1b2pre all day without MOZ_DISABLE_IMAGE_OPTIMIZE on. So far no major issues, no redraw problems. I've been watching the GDI count and it still seems to have a leak somewhere, as when I close all tabs the count never goes back down to initial levels. Without any tabs open, on the google homepage, firefox.exe has 1276 GDI objects allocated. But again, so far it doesn't seem to be causing the previous issue, just thought you should know.
I am still having a problem with minefield (3.1b2pre). I went here: http://hosted.ap.org/specials/interactives/_lifestyles/political_pumpkins/ and opened one of the patterns. The PDF file did not display properly, even when I resize the window. The GDI count stays right around 1200 with the PDF open or closed (I have a bunch of tabs open).
Sorry, I think I spoke too soon. This looks to be an acrobat reader problem, because it shows up in the regular program, even after I shut down firefox.
I have noticed this as well with acrobat, if firefox has a problem then acrobat will not work either.
Vlad, I've been running 3.1b2pre for a week now and 0 problems, GDI still seems high (stuck at 1200 right now) but that's no real issue. Just curious if this patch made it into the 3.1 beta1 build? It would be nice to get the use of extensions back, thanks.
I too have the same issue. NVIDIA Quadro FX 3500 video card. When running 3.1b2pre since 10-21-08, issue is gone.
Hi - I see the status on this is "resolved fixed". But the only way I have been able to resolve this is by installing a nightly build which disables my extensions.. So I am back to FF2. It is not in the beta 1 build according to the fixed bug list, and I confirmed by going to cersibon.blogspot.com with the beta and having the same issue. As a first time user on bugzilla it is not clear to me from the details listed above how to implement this fix other than a nightly build. Thanks.
Seanie, I'm afraid that's the only way to get this fix.
(In reply to comment #117) > Seanie, I'm afraid that's the only way to get this fix. Bummerrrrrr. I guess I will hang in until I see it in a beta. I can't imagine using the internets w/o my Stumble. Thanks for the clarification.
Any ETA for when this is going into the trunk? A thousand thank you's for the fix but I miss add-ons desperately.
Anyone still watching this? No one else wants the fix in the official release?
I am watching this. Desperately need a fix. I saw two releases after this issue was marked as fixed, but I am still experiencing a problem. It's been a month and ten days. Is this bug forgotten?
Flags: blocking1.9.0.6?
In order to be productive at work, I have had to give up using Firefox because of this issue. Everyone else here has been experiencing the same thing.
Attached patch Port the trunk patch to 1.9.0 — — Splinter Review
Attachment #349818 - Flags: review?(pavlov)
FYI for everyone complaining about the bug not being fixed: it IS fixed on the trunk, and it is fixed for the upcoming 3.1 release. The fix just hasn't been backported for 3.0.x yet. That's what Joe Drew is doing right now, from the look of it. Thanks, Joe.
I am not complaining. I am just patiently watching this bug :-). set MOZ_DISABLE_IMAGE_OPTIMIZE=1 made temporary fix for me. Each 3.0.x release, I am disabling MOZ_DISABLE_IMAGE_OPTIMIZE and hope that issue would be fixed. Now I'll be checking only 3.x releases :-).
Thanks Joe! So branch 1.9.0 corresponds to the 3.0.x version?
That's right. We're targeting this fix for Firefox 3.0.6.
Not a blocker but we do want this fixed and will approve a reviewed patch
Flags: blocking1.9.0.6?
Attachment #349818 - Flags: approval1.9.0.6?
Whiteboard: needs r=pav for branch
How is this is not a critical bug? Not only does it make ALL webpages impossible to use after some time, not just some select ones, it also often requires OS reboot before Firefox becomes usable for some minutes again! It is much worse than other "critical" bugs. I'm sorry but the Firefox team has really dropped the ball here. Can anybody explain to me why this bug is still not fixed in the official release after 7+ months?
I have to agree with pracapl. Firefox has basically become unusable for me at work. I've had to switch to chrome just to stay productive. My development box stays up for long periods of time and I just do not have luxury to be able to bounce my box every couple hours to address this issue. This patch is targeted for 3.0.6 which is slated for release on February 3. 46 days till I can switch back.
Seconding #129/#130 - this is a desperately needed fix... (I've basically given up on FF and switched to Chrome. FF is completely unusable without the fix - at least for me) I've got no idea if there's any way to fast-track the fix, but I'd sure appreciate it to get my mittens on it *before* Feb3. While still being able to keep my plugins - so nightlies are out.
There is no way to fast-track this fix. We fully understand that it's important, which is why the current plan is to include the fix in Firefox 3.0.6, our next scheduled release of Firefox. There's an enormous amount of work involved in releasing a new version, between code changes, building, running quality assurance tests, and finally releasing to the hundreds of millions of Firefox users. Please be patient: we have heard you loud and clear, and we are going as fast as it is possible for us to go.
For the record the problem is gone for me with FF 3.1beta2... thought I have a different issue now, various paletted images turn to yellow/green (I have already reported it using the reporting tools embedded in FF to report misbehaving sites). To any account, I can stand having some weird images, and Chrome does not give me a decent representation of raw XML docs, so here I am with beta2 ;)
Attachment #349818 - Flags: review?(pavlov) → review?(vladimir)
Attachment #349818 - Flags: review?(vladimir) → review+
Comment on attachment 349818 [details] [diff] [review] Port the trunk patch to 1.9.0 Hrm, I think that's ok.. trying to remember if there's anything weird on the 1.9 branch's cairo win32 bits that could impact this, but I don't think there is.
Whiteboard: needs r=pav for branch → needs approval1.9.0.6
Attachment #349818 - Flags: approval1.9.0.6? → approval1.9.0.6+
Comment on attachment 349818 [details] [diff] [review] Port the trunk patch to 1.9.0 Approved for 1.9.0.6, a=dveditz.
Checking in gfx/cairo/cairo/src/cairo-win32-surface.c; /cvsroot/mozilla/gfx/cairo/cairo/src/cairo-win32-surface.c,v <-- cairo-win32-surface.c new revision: 1.63; previous revision: 1.62
Keywords: fixed1.9.0.6
Whiteboard: needs approval1.9.0.6
For those running into the bug, you can try the 1.9.0.6 build from the other night at ftp://ftp.mozilla.org/pub/firefox/nightly/2009-01-16-06-mozilla1.9.0/. The issue should be fixed. We will be making official Firefox 3.0.6 builds in the next couple of days. I'd like to hear, if possible, from someone who can reproduce this problem that the build at the above link fixes it for them. Can one of you respond with whether it does?
The 2009-01-16-06-mozilla1.9.0 build seems to fix the problem on my machine.
I deleted MOZ_DISABLE_IMAGE_OPTIMIZE=1 and looks like build 2009-01-16-06-mozilla1.9.0 works fine. No redrawing issues.
Does anyone know if this bug is at all related to this issue I am also seeing (I can also repro the redraw issue in 3.05 at least). This issue repro's in 3.1b2 ISSUE: Repaint issue if scroll list on Facebook. REPRO: 1. Have more than 50 friends on facebook 2. Go to compose mail and in the TO: field, click to put your cursor there, then press the down arrow to see a list of your friends. (its trying to autocomplete the field for you) 3. Scroll down that list via the down arrow or via the scroll bar 4. Within 55 names, you will see redraw issues, like this...http://brandobean.com/images/facebookredrawissue.jpg This repro's 100%, every time, in both 3.05 and 3.1b2. Is this related? I'm on Vista Sp1.
Firefox 3.0.6 was released today, 2/3/09, and is reported to have this bug fixed. : ))
Sorry, I'm late to this one. I can confirm this is fixed in 3.06!!! The problem only happens for me when I have the monitors in portrait mode. I can recreate the problem in 3.0.5. in a few seconds after booting up by doing the following: 1. Open up Firefox to maps.google.com 2. Maximize Firefox to a screen. 3. Find an area in googlemaps with roads, 4. Hit the zoom in/out button repeatedly, very quickly about 20 times 5. Parts of the browser stops redrawing. When the problem does occur, it start to affect other applications. Acrobat will stop redrawing properly, sometimes MS Word, etc. My configuration: - Dell T7400 Precision Workstation with Quad Core - Quadro FX1700 - Dual Monitors 1600x1200 monitors in Portrait mode (bug does not occur for me in landscape mode) - Dual SCSI drives in RAID0 - Adaptec SCSI controller - XP Pro
It's been a week since I am using 3.06. No issues. Vlad, thank you for returning belief in Firefox.
Issue fixed for me too. No more chrome, and no more 800x600 firefox windows for me!
Same here. Just as I am happily realizing that Firefox has quit doing the redraw issues I am getting them with my Adobe Creative Suite Premium CS4 - so Firefox is not the only prog on the problem with such problems. Thanks for solving it though!
Yes, Firefox is fixed, but I too have the problem with Adobe. Acrobat9 in my case. Maybe the fix for Firefox applies to Adobe?
Guys, this isn't the place to be discussing your problems with Adobe software. Please contact Adobe about your problems and let this bug rest in peace.
Yes, sure. However, I am getting slight redraw problems when using Googlemaps. Nothing apart from OpenOffice Calc running meanwhile. No Photoshop this time;-). However, it seems to disappear after a few seconds Googlemaps got closed.
3.0.6 seemed to fix this problem for me in FF, but it still happens with my desktop refreshing, other programs, etc. The bug isn't yet fully fixed and the fact that it is affecting the rest of my system is really bad. If I close FF, no more problem with the desktop or other apps refreshing.
OK, just a note to everybody who's still talking about redraw issues with other applications. As I said in comment #101: >As for "more a permanent fix", I think the comment says it well: > /* Note that if an app actually does hit this out of memory > * condition, it's going to have lots of other issues, as > * video memory is probably exhausted. > */ >The patch makes Firefox better able to handle the case when video memory is >nearly saturated, but problems may still persist, since the point of the >problem is that you're nearly out of video memory. The fix for this bug makes Firefox not corrupt its own window when your system is running out of video memory. It does not (and cannot!) prevent other programs from running out of video memory. Closing Firefox may reduce corruption in other programs (since closing Firefox frees up video memory resources) but the problem does not lie with Firefox but with the other programs on your system. In short: if you are having problems with some other application not redrawing correctly, it's really the fault of the other application at least as much as it is Firefox's fault. In fact, the real root cause is probably that your video card simply can't keep up with the demand you're placing on it. For anyone with redraw issues, rather than adding more comments to this bug, I would suggest posting your issues to the Firefox forum at http://forums.mozillazine.org/viewforum.php?f=38 .
Frankly, the "it's another applications fault" is a cop-out. Safari, IE and Chrome don't expose that behavior. Firefox 2 doesn't show that behavior. Heavy photoshop sessions don't force other apps to lose video memory. Windowed DX games don't lead to this. It is *only* FF3 that makes other apps misbehave. And the "video card can't keep up with the demand" is just BS. A nVidia 7800 with 512MB VRam is perfectly capable of handling a few measly browser sessions. It's fairly possible that this entire problem is due to broken resource management (or excessive resource use) in FF. I'd suggest the FF team fixes the bug, but that's just my opinion. I'm not going to reopen the bug, because at this point I'm not sure I care anymore. Thankfully there are other decent browser alternatives on Windows.
I agree... I'm not going to reopen the bug either, but I'm still having problems with my system. I use a M6300 at work and having firefox open with excel, acrobat, lotus notes, and sametime makes the whole system go on the fritz. IMO, my 10+ lb engineering laptop should be able to handle this. Even though the firefox redrawing problems are gone, the whole system can't keep up. I love firefox, but if it's causing these problems I just can't live with it.
I don't think it's Firefox. I tried on my system after uninstalling FF and I still get corruption in Acrobat 9 Pro. When that happens, I do get other corruption in Excel. I think the FF problem has been fixed and the problem now is in Acrobat 9.
Sorry, I forgot to add, strangely, I have a very similar configuration at home and at work. Both are Intel quadcore with similar generations of video cards. Both have the same model dual 1600x1200 monitors in portrait. Both run Win XP SP3 and have 4GB RAM. The work system is a Dell w/ Quadro FX1700 is a Dell, the home one is a Gigabyte mobo w X38 chipset. The work machine used to have corruption with FF 3.0.5 the home system never did. So it's more than just FF 3.0.5. There's some other interaction.
I think we should keep the Adobe stuff out of here. It is known for the current Adobe products that they have redraw issues as well, quite apart from having Firefox running. I've seen it already months ago in Illustrator CS4, now Photoshop CS4 together with Dreamweaver cause these issues. No matter if Firefox is open or not. Be it still a problem in Firefox, but the Adobe issue is one to be kept apart.
Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: