Created attachment 342108 [details]
test case (requires signed.applets.codebase_principal_support = true)
On Windows, Flash content is rendered by drawWindow() when wmode is set to transparent or opaque. However if the canvas scale is less than or greater than 100% the Flash content is not rendered.
I created a test case based on the test case for bug 313462. The test at the bottom of the page (50% wmode="transparent") is identical to the other wmode="transparent" test except I added this call before drawWindow():
Nothing is drawn when the scale is set to a value other than 1.0.
Jeff, can you look at this? It works on OSX, fails on Win32 and I assume Linux (?). I'm guessing the native drawing code on those platforms isn't handling something correctly here (gfxWindowsNativeDrawing and friends).
None of these testcases work for me at all.
roc -- Did you set the pref for signed.applets.codebase_principal_support? What platform are you on?
Created attachment 342990 [details]
cleaned up testcase
This gets rid of the need for extra IFRAMEs and makes it more obvious what's going on. For me, all the cases work on Mac, but only the wmode="transparent", unscaled case works for me on Windows.
Created attachment 343002 [details] [diff] [review]
Okay, this fixes transformed windowless plugins, but needs more testing.
For bonus points, I'm going to try using PrintWindow so we can get windowed plugins too.
Kathleen, do you happen to have (or can make) a Flash testcase that's actually transparent? It appears this Flash object paints a white background when wmode="transparent". It would be good to be able to test true transparency.
Created attachment 343004 [details] [diff] [review]
Check this out! It really works. Kinda. There's one problem, which is that if the plugin is scrolled out of view so it's partially clipped by an enclosing widget, Windows' PrintWindow API clips the rendering to whatever it thinks is visible :-(. Still pretty cool though.
Created attachment 343005 [details]
Slightly more complete testcase
Created attachment 343026 [details] [diff] [review]
Okay, this fixes the clipping problem with an evil, EVIL hack --- temporarily reparent the plugin to NULL, i.e. make it top-level while we do the PrintWindow call. Amazingly, it actually seems to work, for Flash anyway.
Vlad, I need your advice. I suspect this patch is going to paint windowed plugins even for the normal paint case, which we don't want since the plugin's window should be doing that, so we'll just be slowing things down with the plugin effectively painted twice. I'm not sure of the best way to avoid this. One way would be to somehow identify paints that are going to the screen --- can we do this? Flags on gfxContext or something?
(In reply to comment #9)
> Vlad, I need your advice. I suspect this patch is going to paint windowed
> plugins even for the normal paint case, which we don't want since the plugin's
> window should be doing that, so we'll just be slowing things down with the
> plugin effectively painted twice. I'm not sure of the best way to avoid this.
> One way would be to somehow identify paints that are going to the screen ---
> can we do this? Flags on gfxContext or something?
Flags would work -- there are already flags on gfxContext, we can just add a FLAG_IS_FOR_PRINTING or something. FLAG_SIMPLIFY_OPERATORS is already being set for printing on win32, at least, so you can just set the other flag there as well.
Created attachment 343402 [details]
Flash project file to build SWF with transparent background
Created attachment 343403 [details]
Flash SWF with transparent background
Created attachment 343404 [details]
Test case that uses transparent swf
(In reply to comment #6)
> Kathleen, do you happen to have (or can make) a Flash testcase that's actually
> transparent? It appears this Flash object paints a white background when
> wmode="transparent". It would be good to be able to test true transparency.
Try this one. I also changed the drawWindow() bgColor parameter to "rgba(0,0,0,0)".
Created attachment 343501 [details] [diff] [review]
okay, I've added code to prevent us from painting a windowed plugin via PrintWindow if we're rendering to a screen --- in most cases. Edge cases where we go through another gfxContext, such as rendering to an offscreen surface for SVG filters, still get rendered with PrintWindow as well as the window showing up, but who cares, that's all broken anyway.
This works great with Kathleen's latest testcase (thanks!). Let's do it!
Do we know if the unittest machines have flash? I suspect the Mac and Windows ones do, but I would guess the Linux ones don't. Would be nice to get a reftest.
Yes, I would really like a reftest here too. This whole area is way undertested.
Who do we lean on to find out about the Flash situation and if necessary, fix it?
Created attachment 343860 [details] [diff] [review]
There was a change to nsWindow.cpp missing from the last patch.
*** Bug 461176 has been marked as a duplicate of this bug. ***
I wonder whether to check in a reftest here.
I think the patch for this bug is causing some strange behavior on my machine. I use the TabPreview plug-in: https://addons.mozilla.org/en-US/firefox/addon/6132 and http://ted.mielczarek.org/code/mozilla/tabpreview/
Any time I hover over a tab to bring up the tab preview (rendered with drawWindow), and the tab in question has an active plug-in (seems to occur most often with Acrobat files open in the browser), before the preview appears, my whole screen quickly flashes with an image of what is in the tab. It feels like the browser is switching to the tab, taking a screenshot and then switching back to my original tab, so it can display the preview. I apologize if my description of what is going on is unclear, as I've been having a hard time figuring it out myself.
My Build ID: Mozilla/5.0 (Windows; compatible; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081030 Minefield/3.1b2pre ID:20081030042430
I tried the previous nightly 20081029 and this wasn't a problem. I hope this helps.
(In reply to comment #20)
Oh, and I should have mentioned, I'm using the latest version of Acrobat/plug-in:
Acrobat 9.0 Pro. Sorry for the extra bugspam.
It's probably the window-reparenting part of the patch. I didn't see a problem in my testing but it wouldn't be surprising if there was one.
Created attachment 345648 [details] [diff] [review]
Let's take this out for now. Some parts of plugins may not paint without it, but that's probably better than arbitrary weirdness. At least we'll have two sets of nightly builds to compare.
Checked that in. Doug Halamay, please retest tomorrow with tonight's nightly build. if there's still a bug, please file a new one.
(In reply to comment #24)
> Checked that in. Doug Halamay, please retest tomorrow with tonight's nightly
> build. if there's still a bug, please file a new one.
Looks fixed to me. Thanks!
BuildID: Mozilla/5.0 (Windows; compatible; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081103 Minefield/3.1b2pre ID:20081103033222