Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100905 Firefox/4.0b6pre With this build, the profile manager window is black. Setting layers.accelerate-all to false does not change the behavior. Even after a restart. The regression window is : http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd474ff6f86c&tochange=fd13b6ce36bd

It's on by default no so you have to explicitly do accelerate-none. But your profile will not be loaded yet when the profile manager is shown. So the best idea is to start in safe mode while we figure out what the problem is!

Could you include some data on your GPU/monitor resolution(s) etc.?

I set layers.accelerate-all to false and layers.accelerate-none to true, and the problem still occurs. I disabled HW acceleration in Options window and the problem still occurs. In safe mode, the problem is gone. Graphic card : Intel GMA 4500M Graphic driver : 8.15.10.2182 Integrated monitor Monitor resolution : 1600x900 Color depth : 32 bit Refresh frequency : 60 Hz

Hrm, that would suggest accelerate-none is not working! We'll need to investigate. Updating your intel graphics drivers might work, although I don't see why this should give you big issues :(.

GMA devices including and under the GMA 4500 are basically fake Dx9 chips that lack TNL and do not have hardware vertex shaders, The drivers also expose caps that the chips don't even support.

sorry, the GMA X4500 is Dx10, there was no 4500(except in poor intel labelling). the drivers are notorious for poor Dx9 caps compliance though.

Scoobi, intel has newer drivers available for the HDx4500 http://downloadmirror.intel.com/19291/a08/GFX_Vista_Win7_32_15.17.10.2189_PV_Intel.exe http://downloadmirror.intel.com/19291/a08/GFX_Vista_Win7_64_15.17.10.64.2189_PV_Intel.exe

With graphic driver version 8.15.10.2189, the problem still persists. With build b6pre/20100904 and layers.accelerate-all set to true, there is no problem. That is why a regression window range is in comment 0.

Not only the profile window complete minefield is black. First appearance with an old GS7300 nVidia card but continues with Intel Controller (Clarkdale) (which has DX10 support according to GPU-Z). System is WXP SP2/32

I too am seeing this problem.

Same BUG here, I have to stick with the 20100903 build to avoid black screens problems. With latest build, profile manager is permanently black whatever layers.accelerate-all status, and set it to false only prevent to get black screen too with the main windows (hopefully). I'm using Windows 7 x64 with Intel drivers 8.15.10.2189, chipset is Intel G45, resolution 1920*1200, directX 10. I can provide any information by request to help correcting this bug.

Here's my version of the problem. I see the black window while starting Minefield (Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre ID:20100907041859). Nothing draws, unusable. But if I hit Ctrl+T, everything starts coming back, and after a full window redraw (minimize/restore, or cover with other window), everything works as if nothing ever happened. This is on a laptop with 965 express chipset. about:support reports the following: Adapter Description Vendor ID 0000 Device ID 0000 Adapter RAM Unknown Adapter Drivers Unknown Driver Version Driver Date Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Layers Enabled 1/1 Direct3D 9 Real data, according to intel drivers is: Driver Version: 6.14.10.5218 Operating System: Windows XP* Professional, Service Pack 3 (5.1.2600) Default Language: Spanish DirectX* Version: 9.0 Physical Memory: 2038 MB Minimum Graphics Memory: 8 MB Maximum Graphics Memory: 128 MB Graphics Memory in Use: 64 MB Processor: x86 family 6 Model 23 Stepping 6 Processor Speed: 2494 MHZ Vendor ID: 8086 Device ID: 2A02 Device Revision: 0C Hope this helps.

(In reply to comment #13) I am seeing same following bug too. https://bugzilla.mozilla.org/show_bug.cgi?id=593678#c13 My workaround is layers.accelerate-all = false. Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre ---- about:support Graphics Adapter Description Vendor ID 0000 Device ID 0000 Adapter RAM Unknown Adapter Drivers Unknown Driver Version Driver Date Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Layers Enabled 1/1 Direct3D 9 Intel(R) Graphics Media Accelerator Driver for Mobile Report ---- information of Intel GMA driver Report Date: 09/08/2010 Report Time[hr:mm:ss]: 09:49:39 Driver Version: 6.14.10.5043 Operating System: Windows XP* Professional, Service Pack 3 (5.1.2600) Default Language: Japanese DirectX* Version: 9.0 Physical Memory: 2006 MB Minimum Graphics Memory:8 MB Maximum Graphics Memory:384 MB Graphics Memory in Use: 55 MB Processor: x86 family 6 Model 15 Stepping 11 Processor Speed: 2194 MHZ Vendor ID: 8086 Device ID: 2A02 Device Revision: 0C * Accelerator Information * Accelerator in Use: Mobile Intel(R) 965 Express Chipset Family Video BIOS: 1668.1 Current Graphics Mode: 1024 x 768 True Color (50 Hz)

It's very important we find a way to reproduce this!

We have one, Beltzner's laptop!

(In reply to comment #1) >So the best > idea is to start in safe mode while we figure out what the problem is! Alternatively I can create a shortcut to a specific profile as a workaround for the black prof mgr window: http://kb.mozillazine.org/Shortcut_to_a_specific_profile and then change layers.accelerate-none to true (to prevent a black main-window in that profile)

Since build b6pre/20100908, it works for me.

Same here, b6pre/20100908 seems to solve this problem, black screens are gone. However in about:support with "use hardware acceleration when available" set to ON, here the results : Direct2D Enabled false DirectWrite Enabledfalse GPU Accelerated Windows 1/1 Direct3D 9 Some accelerations seems to stay off (it worked before). But, as a note, I prefer much more this way, no acceleration but no problem ;-)

(In reply to comment #19) > Same here, b6pre/20100908 seems to solve this problem, black screens are gone. > However in about:support with "use hardware acceleration when available" set to > ON, here the results : > > Direct2D Enabled false > DirectWrite Enabledfalse > GPU Accelerated Windows 1/1 Direct3D 9 > > Some accelerations seems to stay off (it worked before). > But, as a note, I prefer much more this way, no acceleration but no problem ;-) You are getting acceleration! Not Direct2D though, this is probably one of the blacklisting issues.

My profile manager isn't black in today's build

(In reply to comment #20) > (In reply to comment #19) > > Same here, b6pre/20100908 seems to solve this problem, black screens are gone. > > However in about:support with "use hardware acceleration when available" set to > > ON, here the results : > > > > Direct2D Enabled false > > DirectWrite Enabledfalse > > GPU Accelerated Windows 1/1 Direct3D 9 > > > > Some accelerations seems to stay off (it worked before). > > But, as a note, I prefer much more this way, no acceleration but no problem ;-) > > You are getting acceleration! Not Direct2D though, this is probably one of the > blacklisting issues. So, it's a good news if I'm getting a partial acceleration support without black screens issues.

I've still got black with http://hg.mozilla.org/mozilla-central/rev/36f5cf6b2d42 Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre . Details are in my dupe.

Guys, you can't trust Intel graphics to properly support anything, the HD 4k chips don't even properly support Direct3D8

Barry, with tonight's nightly you still have a black profile manager?

Yep. Details are all in Bug 594364. I thought this was supposed to be only turned on for Vista and Win7, not XP. Nothing I ever saw about Layers said it was happening on it.

I've seen some reports on MZ about this being fixed, but I'm with Barry here, still black. Same chipset, same minefield revision

We seem to have a common theme here of Intel drivers. Is it worth changing the title of this bug to limit the scope of it to just Intel chips? Other GPUs aren't likely to share the same problems.

And just for clarity, still busted with http://hg.mozilla.org/mozilla-central/rev/8e0fce7d5b49 - Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre

Not sure if it's the same thing, but immediately after updating to http://hg.mozilla.org/mozilla-central/rev/8e0fce7d5b49 my entire Firefox window turned black, then after scrolling reappeared and then quit responding. Then my TV hooked up via VGA cable quit receiving output for a second. Not a problem with my computer because it just started happening recently and only in Firefox. Nvidia GT 220 with latest driver from Nvidia's site and WIn7 x64.

from about:support - Not an intel gpu Graphics Adapter Description NVIDIA GeForce Go 7800 Vendor ID 10de Device ID 0098 Adapter RAM Unknown Adapter Drivers nv4_disp Driver Version 8.3.2.0 Driver Date Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Layers Enabled 0/2 Still get blank/black browser windows after screen lock with anything after Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100904 Firefox/4.0b6pre Newly opened windows work fine. Can't get the old ones to redraw. Tried layers.accelerate-all = false - nada.

Update: with the 32b tinderbox build in http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1284048228/ and the layers.accelerate-all = false I no longer get the black window

This is a screenshot of the card error driver that's echoed by my win7 (32)

Today's nightly (Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre - http://hg.mozilla.org/mozilla-central/rev/79d0beec27b5 ) is even worse on XP - the usual "adjust the viewport trick" in the browser window to make it redraw the screen properly doesn't work at all any more.

It is not an Intel issue, see comment 32 and bug 595471. D3D is enabled by default on Win2000/WinXP and D3D seems to cause this issue. Does anybody with WinVista/Win7 have this issue ?

(In reply to comment #35) > Today's nightly (Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100910 > Firefox/4.0b6pre - http://hg.mozilla.org/mozilla-central/rev/79d0beec27b5 ) is > even worse on XP - the usual "adjust the viewport trick" in the browser window > to make it redraw the screen properly doesn't work at all any more. I do not have a very good explanation as to why it is so broken for you! But we definitely need to figure this out.

Total shot in the dark, but did Bas's checkins this weekend change any behaviour here?

We're back to the previous behaviour now - the initial black window on both the Profile Manager and initial window creation still occur, but resizing does make everything viewable again. Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100913 Firefox/4.0b6pre Built from http://hg.mozilla.org/mozilla-central/rev/84ee6bc0484d

Of interest is that I can't fix the interior of the Profile Window with a minimize or partial covering with another window, which does fix the initial startup browser window interior... which is probably the same behaviour as before.

Please see my just reported bug 596186 for more details on this.

And the Add-on Update dialog (or maybe it was the Add-on Incompatibility Warning one?) also suffers from this same problem... couldn't tell what it was trying to say, but Enter did get past it. :-)

Joe, we should move forward with this a bit: The regression range for this issue is between http://hg.mozilla.org/mozilla-central/rev/bd474ff6f86c and http://hg.mozilla.org/mozilla-central/rev/fd13b6ce36bd. My rough guess is one of these there: bug 593618, bug 581212, bug 593275. We should check if some of these (or other bug) is a culprit and if we can fix it or back something out to figure out. When I wake up my laptop from standby, Firefox doesn't redraw at all after all attempts and I have to restart it. Quit blocking from my POW.

Honza, waking from standby is a separate issue - bug 593674.

OK, should I check the regression range also for that bug or do you think these two bugs are completely different issues?

These two bugs are completely different issues. :)

I pushed a test patch to Try http://hg.mozilla.org/try/rev/7eea2552a6e7. It would be great if you could try this build out Honza, to see if it fixes it! Thanks a lot.

Bas, I have been experiencing this bug with an Intel(R) Q45/Q43 Express Chipset where the initial window content and chrome is black. After some scrolling, use of menus and interaction with toolbars everything is redrawn properly. I tested the try build from comment 47 and it made no difference to this behaviour.

Arie, are you using the default prefs? i.e., are you forcing on Direct2D? Can you post your graphics information from about:support?

Graphics Adapter Description Vendor ID0000Device ID0000Adapter RAMUnknownAdapter DriversUnknownDriver VersionDriver DateDirect2D EnabledfalseDirectWrite EnabledfalseGPU Accelerated Windows1/1 Direct3D 9

Sorry, submitted too early I'm using default prefs Windows XP SP3 UA: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre Graphics Adapter Description Vendor ID 0000 Device ID 0000 Adapter RAM Unknown Adapter Drivers Unknown Driver Version Driver Date Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9

Do you happen to know what type of graphics adapter is in your system?

(In reply to comment #52) > Do you happen to know what type of graphics adapter is in your system? The best I can figure out is "Intel Graphics Media Accelerator 4500" which is the standard adaptor which comes with this PC. It's a ThinkCentre Model 7220-ACM

its a GMA x4500/4500, DirectX 10 compliant, has some issues with Dx8 and Dx9 compatibility. 10 pixel pipelines, and a pretty pathetic implementation of opengl 2.1 (fails many GLSL tests)

Minefield crashes on start up when I updated to the 0916 nightly build. I am runing on Windows 7 Home Premium 64 bit with Intel onboard graphics. 0915 build starts up fine. From the about:support page Graphics Adapter Description Intel(R) HD Graphics Vendor ID 8086 Device ID 0046 Adapter RAM Unknown Adapter Drivers igdumd64 igd10umd64 igdumdx32 igd10umd32 Driver Version 8.15.10.2189 Driver Date 7-28-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 2/2 Direct3D 9

Michael, This is not a forum. Please, file a new bug. Don't forget to report the crash id : https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

(In reply to comment #47) > I pushed a test patch to Try http://hg.mozilla.org/try/rev/7eea2552a6e7. > > It would be great if you could try this build out Honza, to see if it fixes it! > Thanks a lot. It behaves the same way, sorry.

With the title change, am I to assume that now Windows 7 laptops with on-board graphics cards are now able to take full advantage of HW without the black screens?

(In reply to comment #58) > With the title change, am I to assume that now Windows 7 laptops with on-board > graphics cards are now able to take full advantage of HW without the black > screens? It should certainly be able to yes. But we know there's still machines out there which are seeing black screens!

OK, 0x0046 is Intel Mobile HD Graphics (4500 family). Notice that in bug 595364 comment 17 we have someone reporting a crash on startup with this card. Should we just blacklist it for now and get Intel to do their homework ? :-P

We desperately need to know how many people this affects. We can't release beta 8 without knowing that information, and if it's a lot, we can't release beta 8 without this fix.

(In reply to comment #61) > We desperately need to know how many people this affects. We can't release beta > 8 without knowing that information, and if it's a lot, we can't release beta 8 > without this fix. Take the percentage of Graft Box submitters with Intel Graphics Card + Windows XP and apply that percentage to Firefox users worldwide.

Bug 600388 (screen lock black browser on XP with Intel graphics) would also likely get fixed with this problem resolved as well.

(In reply to comment #63) > Bug 600388 (screen lock black browser on XP with Intel graphics) would also > likely get fixed with this problem resolved as well. It's unrelated, it happens on other hardware as well. (In reply to comment #62) > (In reply to comment #61) > > We desperately need to know how many people this affects. We can't release beta > > 8 without knowing that information, and if it's a lot, we can't release beta 8 > > without this fix. > > Take the percentage of Graft Box submitters with Intel Graphics Card + Windows > XP and apply that percentage to Firefox users worldwide. That would be inaccurate, considering we haven't got a single Intel machine in house with Windows XP that reproduces this problem.

(In reply to comment #64) > That would be inaccurate, considering we haven't got a single Intel machine in > house with Windows XP that reproduces this problem. UH? I don't get the point here. For "Graft Box submitters" I mean "Firefox trunk/beta users who installed Graft Box add-on, run the test suite and then submitted it to Mozilla".

(In reply to comment #65) > (In reply to comment #64) > > That would be inaccurate, considering we haven't got a single Intel machine in > > house with Windows XP that reproduces this problem. > > UH? I don't get the point here. For "Graft Box submitters" I mean "Firefox > trunk/beta users who installed Graft Box add-on, run the test suite and then > submitted it to Mozilla". Oh right, I understand what you mean, I don't think a lot of people experiencing the issue of their browser being completely unusable will be submitting Grafxbot though. So the actual percentage will be higher than that.

After talking with Bas for a while on IRC, I'll just start throwing all the info I can think of to see if anything helps. First, test environment, it's the same as comment 13, but now correctly reported after bug 594976 got fixed (except for bug 591787). It's an HP laptop Pavilion 6700. According to CPU-Z, the mainboard manufacturer is Quanta, model 30CC(79.2E), chipset GM965 REV C0, southbridge is Intel 82801HBM (IC8-ME). Bios from Hewlett Packard F.58 dated 2008-06-16 (latest according to HP). I'll upload later the GPU info informed by GPU-Z. It's all tested using a rather clean profile, no extensions, no session saving, and all the history gets deleted on close. So I can start from scratch every time. Build Id is Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre ID:20100929041446. Now to the real info... If i start firefox, everything is black (if menubar is active, I can see the title bar). Tabs on top/bottom makes no difference. Switching windows doesn't help, resizing doesn't help either. The only thing I've found that makes it all work again is opening a new tab. After the new tab is open, Chrome and content start drawing as soon as they are invalidated, so switching windows makes everything go back to normal. It stays ok until I close firefox, no known glitches/crashes. A few weird things, if I open a new window (Ctrl+N) while main window is still black, new window is black too. If I open a new tab (Ctrl+T) in any of the windows, both start working ok. I don't know what's the magic behind this "new tab", but it's really strange. HTH. Pablo.

This is to show how the new things get invalidated. You'll see that I'm using some userchrome.css to change the size of tabs, but removing it doesn't change the results

Was a fix pushed? After updating to today's build (Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre Firefox/4.0b7pre ID:20100929041446) Minefield started without any problems on my Intel graphics system. No black window, no paint errors, everything fine. On the previous build there were black windows and painting errors.

A fix was pushed blacklisting lots of old Intel drivers that were known to crash. If you upgrade your Intel driver to the latest from intel.com you won't be blacklisted, so you'll get HW acceleration --- but that means that you might hit bugs again.

Thanks for the info. I'll try to get new drivers.

In my environment (comment #14) seems to have fixed this problem. now using: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre

(In reply to comment #74) > In my environment (comment #14) seems to have fixed this problem. > > now using: > Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre If you didn't update your driver, I'm pretty sure it was just blacklisted, not solved. Please check about:support to see if it shows still 1/1 or 0/1. My guess is that your case is the same as comment 71

Still reproducible on my environment. Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre Graphics Adapter Description Mobile Intel(R) 965 Express Chipset Family Vendor ID 8086 Device ID 2a02 Adapter RAM Unknown Adapter Drivers igxprd32 Driver Version 6.14.10.5218 Driver Date 1-13-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 0/1

RNicoletto, If you get the graphic info with a new profile, D3D9 is declared as disabled and should not, please see bug 600625 which is for the moment only Windows 2003 and add a comment. If you get this info in safe mode, then it is normal.

Just found another workaround. If the menubar is hidden pressing the firefox button makes everything start drawing. But if menubar is active, pressing alt, or clicking on it, or opening the system menu doesn't change anything and everything stays black. I probably should add that this testing profile uses about:blank as a home page and doesn't do session restore. My regular profile, which has session restore active, stays black for a few seconds, and then redraws the entire window normally.

Wow, this is pretty big news, because this means that we're actually able to draw stuff on this graphics card/driver. I wonder what is triggered by your workaround.

I have no idea what a new tab or opening the firefox button may do, but certainly works, and after that, everything is like nothing ever happened. If everything is ok, tomorrow Bas is going to try to do a remote debug from my machine, to see if he can find anything, Fingers crossed!!

Grafx Bot info for my GPU: http://brasstacks.mozilla.com/resultserv/data/results/2db8b752-d772-4c50-bb5f-8983f5179211

Workaround in comment 78 do nothing for me. DirectX Diagnostic Tool ==> http://yfrog.com/9gdxdiagnp GPU-Z ==> http://yfrog.com/m9gpuzig Firefox 4 Home Page + Proxy Auth request ==> http://yfrog.com/izbugloginwithproxyauthrep Firefox 4 Home Page loaded ==> http://yfrog.com/4jbugnewprofilep.th.jpg

RNicoletto, once you get to the point where anything is drawn, the rest just needs to be invalidated. So,when you get to the point of the last image in comment 82, switching to another window and returning to firefox should just work. Please confirm. Thanks

Confirmed. (almost) Initial painting (KO - as per comment 82) ==> http://yfrog.com/j1bug1ltp 2nd painting (OK - as per comment 84) ==> http://yfrog.com/5cbug2tp Now, look what happens if after initial painting I switch to a window app SMALLER than Firefox window: 2nd painting ==> http://yfrog.com/jcbug3psp smaller window example ==> http://yfrog.com/j9bug4g

I debugged this with the help of Honza today. It seems Intel drivers on XP may not always initialize shader constants to 0. Since we rely on them being initialized to 0 for RenderTargetOffset this breaks some things. Manually setting this will fix it!

Comment on attachment 480242 [details] [diff] [review] Initialize RenderTargetOffset shader constant With the symbolic constant

Comment on attachment 480242 [details] [diff] [review] Initialize RenderTargetOffset shader constant a=me for checkin to b7

http://hg.mozilla.org/mozilla-central/rev/b5af89c610e2 should fix all XP problems. We should blacklist Windows 2000.

Bas, sorry I couldn't be here today to do the testing, but I can confirm that this solves the problem for me using changeset 9c2484dac245 . Thanks!!!