User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre Build Identifier: This is a spin-off from bug 611698 comment 103 per roc. On some machines (namely, my own), it appears that the patch for bug 611698 (https://hg.mozilla.org/mozilla-central/rev/fbf144260d6c) does not fix the problem (Flash text rendered with black surface behind, should be transparent). I'm guessing that for some reason the SPI hook is not working (although I have nothing to really back up that theory, and something else could be going on). Reproducible: Always Steps to Reproduce: 1. Open www.skihood.com with a build including changeset fbf144260d6c 2. Observe flash text rendered with a black, non-transparent background I'm running Windows 7 x64 Professional, with OOPP enabled (and if I disable OOPP, the original bug goes away). Also, I have ClearType enabled, and disabling ClearType in the Windows control panel and restarting Firefox also fixes the original bug.

Do you have Visual Studio C++ (any version) or WinDbg installed? If not, installing WinDbg is probably your best bet.

I can install WinDbg. Assuming I've done that, what do I need to do?

Set up the symbol server as documented here: https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server#Using_the_symbol_server_in_Windbg Run Firefox, attach WinDbg to plugin-container.exe, set a breakpoint on User32SystemParametersInfoHook, and load a page containing the Flash object that's causing a problem for you. For each call to User32SystemParametersInfoHook, log the uiAction parameter and whether we reached the line "*((UINT*)(pvParam)) = FE_FONTSMOOTHINGSTANDARD;". Thanks!!!!

OK. I think I'm doing this right, but I never seem to break, so I'm going to list my steps and you can let me know if I'm just missing something. 1. Open Firefox (latest nightly - do I need to be using the debug nightly?) 2. Open a page with a plugin to get plugin-container.exe to run 3. Start WinDbg (I've already set up the symbols and source servers). From the MDC pages, it looks like I'm supposed to be running the x86 version (not the x64, even though I'm on Win 7 x64). 4. Select File > Attach to a Process... and select plugin-container.exe 5. Wait for all of the various modules to load. 6. Edit > Breakpoints... Enter User32SystemParametersInfoHook and click OK. 7. Debug > Go 8. Reload the page with the Flash object that still shows the bug in Firefox. 9. Wait for breakpoint to be reached (this never seems to happen, though). Is there something I'm doing wrong? Can I test by breaking on something else that I should be guaranteed to break on? Thanks for the help.

It might be interesting to try breaking on "SystemParametersInfoW". If that fails perhaps test with "malloc".

(In reply to comment #5) > It might be interesting to try breaking on "SystemParametersInfoW". > If that fails perhaps test with "malloc". Thanks! I broke on SystemParametersInfoW and noticed that guard32.dll seemed to be involved somehow. guard32.dll is a part of the COMODO firewall software that I use. After some investigation, it seems that the Defense+ portion of the firewall was somehow detecting plugin-container.exe as doing a shellcode injection (buffer overflow). By adding plugin-container.exe as an excluded process in the Defense+ settings > Execution control settings > Detect shellcode injections > Exclusions... in COMODO, the black background on Flash objects goes away. I have no idea why Comodo seems to be intercepting the calls to SPI, but it is definitely the culprit here. I'm not sure that leaving plugin-container as an excluded process is a great idea, but I'll live with it. If anyone has any further ideas, I'd be happy to hear your thoughts. And thanks for all the help!

Thanks for the info. That's very interesting ...

Duplicate as bug 626206 ?

That's what I suggested in bug 626206 comment 17, but roc says it's not a dupe

When bug 626602 lands we will take out the SPI hook and this bug will become a non-issue.

Bug 626602 landed.