Closed Bug 611698 Opened 14 years ago Closed 13 years ago

Flash text rendered with black surface behind, should be transparent

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(blocking2.0 betaN+)

VERIFIED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: dbcooper.nz, Assigned: jimm)

References

()

Details

(Whiteboard: [hardblocker])

Attachments

(5 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101112 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101112 Firefox/4.0b8pre

Page uses flash fonts for headings, these are now rendered with the background surface black (rather than transparent), making them impossible to read. Reproduced with safe mode as well.

Videocard is ATI 4650 with 10.10 drivers.

Reproducible: Always

Steps to Reproduce:
1. Visit link
2. Observe Headings
3. Compare with older nightly builds or another browser
Actual Results:  
See following link for screencap:

http://i1099.photobucket.com/albums/g383/dbcooperdk/ff4nightly-1.png



Expected Results:  
See following link for screencap from Chrome (canary build):

http://i1099.photobucket.com/albums/g383/dbcooperdk/chrome_canary.png
Hrm, I wonder if Flash is using GDI in this case and overwriting the transparency bits that they normally keep correctly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking2.0: --- → ?
BTW, I have D2D/DW off and D3D9 for compositing on. (2/2 Direct3D 9)

Flash plugin is 10.1.102.64
I can confirm with D3D10; it doesn't depend on the graphics configuration: Flash is setting pixels to 100% opacity that shouldn't be, probably using GDI functions. What's weird is that this normally works because Flash bitblts/AlphaBlends onto our drawing surface, and I don't understand what's different here.
Is the plugin instance completely opaque in this case?

Is Flash reporting that via the NPAPI transparencybool API?
Depends on: 611539
Hardware: x86_64 → x86
Blocks: 596451
Works;
http://hg.mozilla.org/mozilla-central/rev/212a391d3b79
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101109 Firefox/4.0b8pre ID:20101110052514
fails:
http://hg.mozilla.org/mozilla-central/rev/bdbef533364f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101109 Firefox/4.0b8pre ID:20101110081923
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=212a391d3b79&tochange=bdbef533364f
This does not happen if I set dom.ipc.plugins.enabled to false.
(In reply to comment #6)
> This does not happen if I set dom.ipc.plugins.enabled to false.

Confirmed. Disabling out-of-process plugins fixes this.
Note that the asynchronous layer-based plugin painting that bug 596451 introduced on Windows only applies with OOPP on, so the observation that disabling OOPP works around this bug is not surprising.
I've contacted Adobe about this, will hopefully hear back soon. This appears to be entirely related to text painting (semi-duplicate bug 612113 is only opaque in the areas where text is painted).
Assignee: nobody → benjamin
blocking2.0: ? → betaN+
So we're looking at a Windows only issue directly related to OOP in Firefox. What version of FF is this related to so we can try to find the regression.
It just landed on trunk a few days ago. The technical details are:

Previously when we asked a Flash plugin to paint, we were painting synchronously against a Windows surface. Now, we are asking Flash to paint against a Shared DIB with alpha transparency. Normally Flash does this correctly, setting the alpha channel. But when painting certain kinds of text, Flash sets the opacity of the entire text area to opaque, even when this is not correct.
Another example for this bug:

http://megaupload.com - the upload controls have black areas around them.
Another Flash oddity is the Yahoo! Thanksgiving logo at www.yahoo.com oddly the Flash element not scaled works fine http://l.yimg.com/cv/ae/us/audience/101123/217x85w4m4d99bn.swf
Blocks: 613406
I'm seeing something like this with the banner on http://www.homeicecream.com/

It seems fully transparent areas are transparent, but everything else is blended onto black, leaving jagged black edges.
jmathies is going to take this. The solution we've decided on for now is to hook calls to ExtTextOut. If any call to ExtTextOut is made while we are painting, we will do alpha recovery.

Let's hope that we don't do alpha recovery in the common case, but we should test that on hulu and embedded youtube before landing.
Assignee: benjamin → jmathies
Whiteboard: [hardblocker]
Blocks: 615119
This doesn't appear to be font calls doing the rendering. The page is using fonts built into flash, so these wouldn't rely on windows system fonts or font rendering calls, AFAICT. I've hooked the text out routines flash imports and they are not getting called.

Some examples:

http://www.foreignaffairs.com/sites/default/themes/sitetheme/sIFR/flash/benton_sans_condensed_bold.swf

http://www.foreignaffairs.com/sites/default/themes/sitetheme/sIFR/flash/benton_sans_condensed_book.swf

http://www.foreignaffairs.com/sites/default/themes/sitetheme/sIFR/flash/georgia.swf

Will keep digging.
In this particular case, this is what we're dealing with:

http://www.mikeindustries.com/blog/sifr/
Note bug 613406 can be detected via hooked text routines.
Attached patch test patchSplinter Review
This detects BitBlt and ExtTextOut and flips mDoAlphaExtraction when detected.
In testing the posted patch, it appears Flash makes copying our incoming paint buffer using BitBlt common practice with windowless plugins. Between the text out routines and blit routines, I was hoping to find a way to detect when alpha extraction was needed on a case by case basis, but this doesn't appear possible. What we need is some way of detecting which flash applets provide valid alpha channel data and which do not. So far I haven't found a way to do this through api inspection.
After chatting with bsmedberg, the 'solution' we've decided on is to turn alpha extraction on for flash in general. We're currently using this in 3.6, so the performance impact shouldn't be major.
We are not using alpha extraction in the common case in 3.6; AFAIK we are only using it while printing, and for cases where the plugin is being transformed/rotated, which is very uncommon. I do expect it to cause performance problems of unknown magnitude.
Can't your hooks check the dest DC to see if it's our DC? If it's not doing the operation to our DC, we can ignore the call.
(In reply to comment #32)
> Can't your hooks check the dest DC to see if it's our DC? If it's not doing the
> operation to our DC, we can ignore the call.

I was checking the src dc to detect copy from our surface. These tend to match another call which I'm guessing is the copy back to our surface. I can confirm that to be sure.
Yeah, looks like they do that on at least some of those pages ... BitBlt from our DC to their own DC, then later BitBlt back from their DC to our DC.
BitBlt is not alpha-aware. Presumably they only BitBlt areas where the content is actually opaque. Same goes for ExtTextOut etc. What if, when we detect a BitBlt into our DC, we just set the alpha values of the affected region of our surface to 0xFF? We could do the same for ExtTextOut. No alpha recovery needed.
Yeah, I think that should work. Effectively we're hooking the GDI functions to make them set the right alpha values when they draw to our DC.
I guess for BitBlt that works, but for ExtTextOut we'd have to trigger alpha recovery because we don't know exactly which pixels should be touched.

But even if we only update the alpha values for BitBlt, and trigger alpha recovery in other cases, that should solve the problem in comment #29.
(In reply to comment #35)
> BitBlt is not alpha-aware. Presumably they only BitBlt areas where the content
> is actually opaque. Same goes for ExtTextOut etc. What if, when we detect a
> BitBlt into our DC, we just set the alpha values of the affected region of our
> surface to 0xFF? We could do the same for ExtTextOut. No alpha recovery needed.

(In reply to comment #37)
> I guess for BitBlt that works, but for ExtTextOut we'd have to trigger alpha
> recovery because we don't know exactly which pixels should be touched.
> 
> But even if we only update the alpha values for BitBlt, and trigger alpha
> recovery in other cases, that should solve the problem in comment #29.

I'd be willing to bet ExtTextOut always writes to their internal dc, in which case maybe we don't need to worry about these calls. I'll take a look at the BitBlt idea. Not sure how well it would work for cases like this:

http://www.communitymx.com/content/source/E5141/wmodetrans.htm
Hmm, I don't have an ExtTextOut example to test with anymore, www.punypng.com fixed their flash a few days ago.
Never mind, I was completely wrong in comment #35. Sorry for wasting your time.
I have another suggestion instead. Is it possible to get the plugin to use a different drawing method (i.e. AlphaBlend) by messing with GetDeviceCaps(RASTERCAPS) or even just returning false for the BitBlt call?
Most of the examples in comment #25 work for me on Windows. In some cases we seem to sometimes lose the antialiasing at the edges of the plugin, but it's not severe. Is that what other people are seeing, or do other people see worse effects?
In particular the example in comment #0 seems to work fine for me ... windows 7, D3D10, OOPP enabled. Is it working for everyone now?
This problem still happen on the URL.
http://hg.mozilla.org/mozilla-central/rev/54184cfa6f0e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre ID:20110113030355
  Graphics

        Adapter Description
        ATI Radeon HD 4300/4500 Series

        Vendor ID
        1002

        Device ID
        954f

        Adapter RAM
        512

        Adapter Drivers
        aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.801.0.0

        Driver Date

        Direct2D Enabled
        true

        DirectWrite Enabled
        true

        WebGL Renderer
        ATI Technologies Inc. -- ATI Radeon HD 4300/4500 Series        -- 3.3.10362 Compatibility Profile Context

        GPU Accelerated Windows
        1/1 Direct3D 10
Weird. That sounds just like my machine except I have NVidia hardware. Anyway the plugin-container doesn't interact with D3D at all currently.
It still happens for me at the Foreign Affairs URL from the original bug filing.

Flash 10.1.102.64

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre

Adapter Description	ATI Radeon HD 4600 Series 
Vendor ID	1002
Device ID	9498
Adapter RAM	512
Adapter Drivers	aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Driver Version	8.801.0.0
Driver Date	
Direct2D Enabled	true
DirectWrite Enabled	true
WebGL Renderer	TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 13 2011 03:37:36)
GPU Accelerated Windows	1/1 Direct3D 10
Ah, I have Flash version 10.0.32.18. Who wants to be Adobe broke our approach in 10.1?
(In reply to comment #42)
> I have another suggestion instead. Is it possible to get the plugin to use a
> different drawing method (i.e. AlphaBlend) by messing with
> GetDeviceCaps(RASTERCAPS) or even just returning false for the BitBlt call?

Flash ignores the result of its BitBlt call so that part can't work.
It only calls GetDeviceCaps for PLANES and BITSPIXEL so that won't work either.
FWIW Windows returns 1 and 32 respectively.
(In reply to comment #9)
> I've contacted Adobe about this, will hopefully hear back soon. This appears to
> be entirely related to text painting (semi-duplicate bug 612113 is only opaque
> in the areas where text is painted).

Are you getting any help from Adobe here?  This issue does not appear in other non-Internet Explorer browsers, so there is something wrong with the way the Firefox 4 code renders Flash content over 3.6, which works fine.

Why can't you look at the 3.6 code, which works, and copy it to Firefox 4, updating whatever lines are necessary working with Adobe?
I did a bunch of disassembling of Flash 10.1 on the foreignaffairs URL. Basically it does something like this:
   // At startup:
   hbitmap = CreateDIBSection(..., &ptrbits, ...);

   // At each paint:
   hdc = CreateCompatibleDC(browserDC);
   SelectObject(hdc, hbitmap);
   BitBlt(hdc, ..., browserDC, ...);
   // ... draw over ptrbits ...
   BitBlt(browserDC, ..., hdc, ...);
   DeleteDC(hdc);

It turns out that the first BitBlt preserves our zero-alpha-value data just fine as it copies into ptrbits. It's Flash's own "draw over ptrbits" code that sets all the alpha values to 0xFF, apparently :-(. From then on we're doomed.

So basically, the assumption/observation that Flash leaves any kind of alpha values in its buffer is wrong :-(.
(In reply to comment #53)
> Are you getting any help from Adobe here?  This issue does not appear in other
> non-Internet Explorer browsers, so there is something wrong with the way the
> Firefox 4 code renders Flash content over 3.6, which works fine.
> 
> Why can't you look at the 3.6 code, which works, and copy it to Firefox 4,
> updating whatever lines are necessary working with Adobe?

We can't do that because of our GPU acceleration work. Flash wants to get the current data into system memory and draw over it, and that just falls flat on its face when the data is in video memory. (We *could* bring it back over from VRAM, but that would probably be even slower than double-painting with alpha recovery.)
Good news!!!!!!!!!

I was wondering why Adobe would make this change to copy our pixel data into their buffer, draw over their buffer, and copy back to our buffer. Those extra copies must hurt compared to just using AlphaBlend. I also noticed that on the communitymx example they are doing the two BitBlts but the alpha values are correct, not replaced with 0xFF! The only reason I could think of for doing this extra blitting is if they're doing subpixel-AA so AlphaBlend isn't sufficient. So I hooked SystemParametersInfo and observed that they call it twice: once for SPI_GETFONTSMOOTHING and once for SPI_GETFONTSMOOTHINGTYPE. So on a hunch I turned off Cleartype on my system and presto, this bug no longer manifests!

So basically, when subpixel-AA is disabled they'll give us good alpha values, otherwise they'll give us bad alpha values. The thing is, we're reducing them to a single alpha channel anyway, so their subpixel-AA can't work with our async drawing model. So I think we should hook SystemParametersInfo and pretend Cleartype is disabled. And then we should be all good! Except that subpixel-AA will be disabled in Flash. So we should make sure that whatever next-gen drawing API we come up with can handle subpixel-AA.
That sure does seem to work. I'll send this to try for some builds. Thanks roc!
Comment on attachment 503799 [details] [diff] [review]
hook spi for cleartype  setting v.1

actually, I need to quirk that to flash only.
Attachment #503799 - Attachment is obsolete: true
try builds should show up here in a bit:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-cdc83f0f6c65

Locally this fixes the issue in our test cases for me.
Comment on attachment 503804 [details] [diff] [review]
hook spi for cleartype setting v.2

Test cases WFM with that try build.
Attachment #503804 - Flags: review?(roc)
http://hg.mozilla.org/mozilla-central/rev/fbf144260d6c
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
A few things sprung to mind while I was out shopping:
1) We should do this for all plugins. None of them are going to be able to do subpixel-AA when we're reducing everything to RGBA.
2) We should not override the font smoothing settings when the plugin instance is in opaque mode. In that case, subpixel-AA will work fine.
3) We should have a test. It should be easy to extend the test plugin to test this.

I guess we should have followup bug(s) for 1 and 2.
Just a question:

When a bug is set to "RESOLVED FIXED" is the patch then applied to one of the next hourly builds or to the next Nightly build on (nightly.mozilla.org)?
(In reply to comment #64)
> Just a question:
> 
> When a bug is set to "RESOLVED FIXED" is the patch then applied to one of the
> next hourly builds or to the next Nightly build on (nightly.mozilla.org)?

Depends. mc is a little backed up today, you can see the status of the win builds here:

http://tbpl.mozilla.org/?noignore=0

(In reply to comment #63)
> A few things sprung to mind while I was out shopping:
> 1) We should do this for all plugins. None of them are going to be able to do
> subpixel-AA when we're reducing everything to RGBA.
> 2) We should not override the font smoothing settings when the plugin instance
> is in opaque mode. In that case, subpixel-AA will work fine.
> 3) We should have a test. It should be easy to extend the test plugin to test
> this.
> 
> I guess we should have followup bug(s) for 1 and 2.

I'll file that as one bug, those are easy changes.
Blocks: 625933
Hmmm...I downloaded the latest hourly with this patch (Built from http://hg.mozilla.org/mozilla-central/rev/fbf144260d6c) and I'm still seeing this bug (on both the URL in the bug and on several other sites I visit (for example, www.skihood.com).  This occurs both on my daily-use profile and on a brand new blank profile.  I'm using the latest flash version (10.1.102.64).

My graphics info (if that helps):
Adapter Description: NVIDIA GeForce 8800 GTS
Vendor ID: 10de
Device ID: 0193
Adapter RAM: 640
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version: 8.17.12.6099
Driver Date: 10-16-2010
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7600.20830)
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 14 2011 06:29:43)
GPU Accelerated Windows: 1/1 Direct3D 10
I don't know - according to the link listed in comment 65, this bug is listed under one of the "12 Jobs are Failing" under jmathies - Win opt.....whatever that means (Job Failing).

What I get out of it is the patch hasn't landed yet if the build job failed on (http://tbpl.mozilla.org/?noignore=0).

Mozilla?
You want to elaborate and explain what it means on the above page if "Jobs are Failing"?  Not everyone is familiar on how to read the TBPL page.
Wait!

I think I  see the reason why this patch is failing.

Jim Mathies – [Bug 611689] - Mask ClearType settings from flash to prevent paint

The bug number is WRONG and should be 611698.

You have a digit transposition with the last two numbers, Jim.

Bug 611689 = "API keeps getting internal server errors" and has nothing to do with Flash.  Last modification was in November 2010, so I assume that one has already landed.
The patch wouldn't fail for a typo in the bug number in the commit message.
Alice:

I used the following Hourly (1295033147-20110114112547-bfdbd09c805e-firefox-4.0b10pre.en-US.win32.zip); Time = 18:45 and still see the black boxes of Flash.
MOZILLA - REGRESSION HERE!!!

20110114141822 = Works (Time = 16:50)
20110114112547 = BROKEN (Time = 18:45)
(In reply to comment #71)
> Alice:
> 
> I used the following Hourly
> (1295033147-20110114112547-bfdbd09c805e-firefox-4.0b10pre.en-US.win32.zip);
> Time = 18:45 and still see the black boxes of Flash.
You should use build fbf144260d6c or later.
Alice:

I am referring to the following site:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/


1295052398-20110114164638-09941c7a591f-firefox-4.0b10pre.en-US.win32.zip	14-Jan-2011 19:00 	14M	*** WORKS *** 

1295043502-20110114141822-fbf144260d6c-firefox-4.0b10pre.en-US.win32.zip	14-Jan-2011 16:50 	14M	*** BROKEN ***


There was also an 18:45 time build, but it has been replaced with the 19:00 one, which now works.
(In reply to comment #75)
> Alice:
> 
> I am referring to the following site:
> http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/
> 
> 
> 1295052398-20110114164638-09941c7a591f-firefox-4.0b10pre.en-US.win32.zip   
> 14-Jan-2011 19:00     14M    *** WORKS *** 
> 
> 1295043502-20110114141822-fbf144260d6c-firefox-4.0b10pre.en-US.win32.zip   
> 14-Jan-2011 16:50     14M    *** BROKEN ***
> 
> 
> There was also an 18:45 time build, but it has been replaced with the 19:00
> one, which now works.
You should check the order of checked-in on http://hg.mozilla.org/mozilla-central/log.
Just did a fresh build off mozilla-central. Open espn.com and look at the poll in the middle about halfway down the page. The text still looks awful even post-patch.
Sorry....I am seeing fbf144260d6c working.
(In reply to comment #77)
> Just did a fresh build off mozilla-central. Open espn.com and look at the poll
> in the middle about halfway down the page. The text still looks awful even
> post-patch.

Go to http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/

Are you using AT LEAST the build with the time of 16:50 or later?
(In reply to comment #75)
Some builds take longer to create than others, especially if they fail tests.  So pay no attention to the time the file was saved, its not a true indication of which build it is, only the changeset id, since they can take different amounts of time to create.  What is important is what changeset its built from and the changesets built after it landed on the pushlog, which might be full clobber builds.  
http://hg.mozilla.org/mozilla-central/pushloghtml

Confirming its fixed.
Using Hourly built from changset:
http://hg.mozilla.org/mozilla-central/rev/fbf144260d6c
Thanks Dale.

Please just check all sites with tomorrow morning's build. If you see any issues with a specific site please post them here with detail. I'll file follow ups.
(In reply to comment #79)
> (In reply to comment #77)
> > Just did a fresh build off mozilla-central. Open espn.com and look at the poll
> > in the middle about halfway down the page. The text still looks awful even
> > post-patch.
> 
> Go to http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/
> 
> Are you using AT LEAST the build with the time of 16:50 or later?

Chris, I do my own builds. I did a fresh hg pull immediately prior to building...
(In reply to comment #70)
> I checked the following site with latest hourly build.
> In these site that I tried, the problems seem to have been fixed.
> http://hg.mozilla.org/mozilla-central/rev/fbf144260d6c
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110114
> Firefox/4.0b10pre ID:20110114141822
> 
> fixed: http://www.homeicecream.com/
> Server not found: http://disney.de/disneyxd/
> fixed: http://megaupload.com/
> *not try: http://oscar-raul.superpokepets.com/
> *not try: http://www.inimacopiilor.ro/campanie/ajuta_promoveaza.php
> fixed: http://www.punypng.com/
> fixed: http://www.telusmobility.com/en/BC/plans/
> fixed: http://www.foreignaffairs.com/issues/2010/89/6
> fixed:
> http://www.support.philips.com/support/sms_page.jsp?userLanguage=en&userCountry=my
> fixed: http://www.logitech.com/en-us/gaming/controllers/devices/288
> *fixed by site:
> http://tinypic.com/view.php?pic=8zfzar&s=5&hid=1&tag=flower+icon
> fixed: http://www.skihood.com/

For http://www.inimacopiilor.ro/campanie/ajuta_promoveaza.php (add-peel) - this bug is FIXED
For http://oscar-raul.superpokepets.com/ this bug is NOT fixed. (Menu and flash games is with black background)!
See in attachements.
My Minefield: Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre ID:20110115030345
about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/3d4620449437
Build platform
target
i686-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 	14.00.50727.762 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 	14.00.50727.762 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-tests

Flash:
Shockwave Flash

    Fișier: NPSWF32.dll
    Versiune: 10.2.161.23
    Shockwave Flash 10.2 d161

Tip MIME 	Descriere 	Sufixe
application/x-shockwave-flash 	Adobe Flash movie 	swf
application/futuresplash 	FutureSplash movie 	spl
Shockwave for Director

    Fișier: np32dsw.dll
    Versiune: 11.5.9.615
    Adobe Shockwave for Director Netscape plug-in, version 11.5.9.615

Tip MIME 	Descriere 	Sufixe
application/x-director 	Shockwave Movie 	dir,dxr,dcr
I can confirm that with today's nightly (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre) I still see black backgrounds behind any flash text on all of the test URLs.
Wait for the next nightly or use an hourly; it's fixed there.
Doug, is that with Flash 10.2?

Maybe this isn't fixed with Flash 10.2. But that's a beta version or something right? 10.1 is the latest download.
(In reply to comment #87)
> Doug, is that with Flash 10.2?
> 
> Maybe this isn't fixed with Flash 10.2. But that's a beta version or something
> right? 10.1 is the latest download.

So, you're going to have to recode the technical Alpha-blend or whatever it is called to also support version 10.2 Flash???
(In reply to comment #87)
> Doug, is that with Flash 10.2?
> 
> Maybe this isn't fixed with Flash 10.2. But that's a beta version or something
> right? 10.1 is the latest download.

No, see Comment 66, I'm using Flash 10.1.102.64.
Flash 10.2 is actually already in the release candidate stage, so it might have to be supported sooner rather than later.
I'm just trying to understand what's fixed and what isn't. Some people are saying it's fixed and some people are saying it's not, and we need to figure out why.
(In reply to comment #91)
> I'm just trying to understand what's fixed and what isn't. Some people are
> saying it's fixed and some people are saying it's not, and we need to figure
> out why.

It looks like the patch has fixed the problem for some and not for others.  It is definitely NOT fixed for me.  In the interest of helping to narrow things down, I'm using Win7 x64 with ClearType on.  From my previous comments, I'm also using the latest released version of Flash (v10.1.102.64) and have the following "graphics" info (in case that helps):
Adapter Description: NVIDIA GeForce 8800 GTS
Vendor ID: 10de
Device ID: 0193
Adapter RAM: 640
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version: 8.17.12.6099
Driver Date: 10-16-2010
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7600.20830)
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 14
2011 06:29:43)
GPU Accelerated Windows: 1/1 Direct3D 10

And this is all with the latest nightly (both with my usual everyday profile and a brand-new blank profile with no addons).  Please let me know if I can do anything else to help troubleshoot.
If you turn Cleartype off manually for all of Windows, is the problem fixed?

Do you have out-of-process plugins enabled?

Just for kicks, what's the changeset ID in about:buildconfig?
(In reply to comment #93)
> If you turn Cleartype off manually for all of Windows, is the problem fixed?
> 
> Do you have out-of-process plugins enabled?
> 
> Just for kicks, what's the changeset ID in about:buildconfig?

So...if I turn off Cleartype manually, close Firefox and open it again, the problem is fixed.  If I then re-enable Cleartype and restart Firefox, the problem is back.  So, it looks like it is most definitely tied to Cleartype.

I do have OOP enabled (dom.ipc.plugins.enabled is true).

And my changeset ID is http://hg.mozilla.org/mozilla-central/rev/3d4620449437
The bug is RESOLVED for me, so here is my system information:

- Windows = Windows 7 64-Bit Home Premium
- Clear Type = ON

- Minefield = 1/15/11
- Minefield Hardware Acceleration = ON

about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/3d4620449437
Build platform
target
i686-pc-mingw32
Build tools
Compiler     Version     Compiler flags
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O
e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl    
14.00.50727.762     -TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi
-Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O
e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl    
14.00.50727.762     -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb
-wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--enable-application=browser --enable-update-channel=nightly
--enable-update-packaging --enable-jemalloc --enable-tests


- Graphics = NVIDIA GeForce 9800M GS (Laptop)
- Graphics Driver = 260.99
- DirectX = 11
- Flash = 10.1.102.64


Just helping to diagnose.....
Here's what I'm seeing on espn.com. The messed up fonts first appeared when this bug appeared, so my assumption was always that they were the same bug. Like Doug, I also am on Windows 7 x64. Unfortunately, I do my own builds off trunk and use mq, so my about:buildconfig last changeset id probably won't be of use. That said, I did the hg pull on this changeset:
http://hg.mozilla.org/mozilla-central/rev/6de914cae124

My cleartype settings are stock OS settings. Yes, it is enabled. Yes, I have OOPP enabled.

Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID: 8086
Device ID: 2a42
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2226
Driver Date: 10-15-2010
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7600.20830)
WebGL Renderer: Intel -- Mobile Intel(R) 4 Series Express Chipset Family -- 2.1.0 - Build 8.15.10.2226
GPU Accelerated Windows: 1/1 Direct3D 10
My (dom.ipc.plugins.enabled) is also true.
(In reply to comment #96)
> Created attachment 504193 [details]
> espn.com poll screenshot
> 
> Here's what I'm seeing on espn.com. The messed up fonts first appeared when
> this bug appeared, so my assumption was always that they were the same bug.
> Like Doug, I also am on Windows 7 x64. Unfortunately, I do my own builds off
> trunk and use mq, so my about:buildconfig last changeset id probably won't be
> of use. That said, I did the hg pull on this changeset:
> http://hg.mozilla.org/mozilla-central/rev/6de914cae124
> 
> My cleartype settings are stock OS settings. Yes, it is enabled. Yes, I have
> OOPP enabled.
> 
> Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
> Vendor ID: 8086
> Device ID: 2a42
> Adapter RAM: Unknown
> Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
> Driver Version: 8.15.10.2226
> Driver Date: 10-15-2010
> Direct2D Enabled: true
> DirectWrite Enabled: true (6.1.7600.20830)
> WebGL Renderer: Intel -- Mobile Intel(R) 4 Series Express Chipset Family --
> 2.1.0 - Build 8.15.10.2226
> GPU Accelerated Windows: 1/1 Direct3D 10

Ryan, do you still see the black boxes on http://www.foreignaffairs.com/issues/2010/89/6 too?  Or is it just the ugly fonts on that espn.com poll?
Interesting, that link works fine (as do the other ones in this bug). Guess the espn.com issue is different after all. Sorry for the noise then.
(In reply to comment #99)
> Interesting, that link works fine (as do the other ones in this bug). Guess the
> espn.com issue is different after all. Sorry for the noise then.

So...for some strange reason the SPI hook isn't working on my machine.  I wonder (not being terribly familiar with how it works)...is it possibly tied to a service that might be disabled?
(In reply to comment #96)
> Created attachment 504193 [details]
> espn.com poll screenshot
> 
> Here's what I'm seeing on espn.com. 

Switching tab helps.
And page scroll also helps.
Doug, can you spin off a new bug about the SPI hook not working on some machines?

Raul, we should spin off a new bug for your situation too. Maybe it's Flash 10.2, maybe it's the same as Doug's bug. Please try turning off Cleartype manually --- if that fixes it, it's probably some variant of Doug's bug.

Ryan, we'd better spin off another bug for the espn.com issue.
Doug, to make progress on your bug you may need to use a debugger. I hope you're up for that :-).
Cleartype on. Windows 7 x64 Pro, Geforce 8600 GT, OOPP on. Flash 10.2 RC (Version: 10.2.152.14; Shockwave Flash 10.2 r152).

I'm not seeing any flash issues on any of the URLs that I've found on this bug unless I'm looking in the wrong place.

Adapter Description NVIDIA GeForce 8600 GT 
Vendor ID 10de
Device ID 0402
Adapter RAM 256
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version 8.17.12.6099
Driver Date 10-16-2010
Direct2D Enabled true
DirectWrite Enabled true (6.1.7601.17105)
WebGL Renderer TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 15 2011 07:29:57)
GPU Accelerated Windows 1/1 Direct3D 10


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre built from http://hg.mozilla.org/mozilla-central/rev/f7ac9667229b.
(In reply to comment #103)
> Doug, can you spin off a new bug about the SPI hook not working on some
> machines?
> 
> Raul, we should spin off a new bug for your situation too. Maybe it's Flash
> 10.2, maybe it's the same as Doug's bug. Please try turning off Cleartype
> manually --- if that fixes it, it's probably some variant of Doug's bug.
> 
> Ryan, we'd better spin off another bug for the espn.com issue.

Filed bug 626202 for my problem.  Not sure how much help I'm going to be, but I'll do whatever is requested of me.
Blocks: 626206
(In reply to comment #103)
> Doug, can you spin off a new bug about the SPI hook not working on some
> machines?
> 
> Raul, we should spin off a new bug for your situation too. Maybe it's Flash
> 10.2, maybe it's the same as Doug's bug. Please try turning off Cleartype
> manually --- if that fixes it, it's probably some variant of Doug's bug.
> 
> Ryan, we'd better spin off another bug for the espn.com issue.

Filed bug 626206 for my problem.
I've verified the fix to the problem as reported in comment #0 by visiting the page in the comment on beta 9, seeing the problem, and comparing to the build candidate for beta 10. Where there were black boxes in beta 9, in beta 10 those appear as headlines as intended.

Using Fx4b10(build1) on Windows 7.
Status: RESOLVED → VERIFIED
is bug 629679 connected to this fix?
It's related, but probably not a regression from this.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.