Last Comment Bug 458928 - drawWindow() does not render Flash content when scale is not 100%
: drawWindow() does not render Flash content when scale is not 100%
Status: RESOLVED FIXED
: fixed1.9.1, mobile
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: Trunk
: x86 Windows XP
: P3 normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
Mentors:
: 461176 (view as bug list)
Depends on: 462397 473580
Blocks: 313462 385435 442109 445595
  Show dependency treegraph
 
Reported: 2008-10-07 11:51 PDT by Kathleen Brade
Modified: 2009-09-29 10:25 PDT (History)
18 users (show)
vladimir: blocking1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (requires signed.applets.codebase_principal_support = true) (1.44 KB, text/html)
2008-10-07 11:51 PDT, Kathleen Brade
no flags Details
cleaned up testcase (1.35 KB, text/html)
2008-10-13 19:15 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
fix (15.22 KB, patch)
2008-10-13 21:36 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v2 (16.48 KB, patch)
2008-10-13 22:12 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
better testcase (1.43 KB, text/html)
2008-10-13 22:13 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
fix v3 (16.75 KB, patch)
2008-10-14 01:51 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
Flash project file to build SWF with transparent background (43.50 KB, application/octet-stream)
2008-10-16 08:38 PDT, Mark Smith (:mcs)
no flags Details
Flash SWF with transparent background (456 bytes, application/x-shockwave-flash)
2008-10-16 08:39 PDT, Mark Smith (:mcs)
no flags Details
Test case that uses transparent swf (1.51 KB, text/html)
2008-10-16 08:48 PDT, Kathleen Brade
no flags Details
fix v4 (18.10 KB, patch)
2008-10-16 20:54 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v5 (19.03 KB, patch)
2008-10-19 20:36 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
vladimir: review+
jst: superreview+
Details | Diff | Splinter Review
remove evil (1.11 KB, patch)
2008-10-30 18:59 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
jst: review+
jst: superreview+
Details | Diff | Splinter Review

Description Kathleen Brade 2008-10-07 11:51:16 PDT
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():

  cx.scale(0.5, 0.5);

Nothing is drawn when the scale is set to a value other than 1.0.
Comment 1 Vladimir Vukicevic [:vlad] [:vladv] 2008-10-07 15:16:29 PDT
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).
Comment 2 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 17:23:09 PDT
None of these testcases work for me at all.
Comment 3 Kathleen Brade 2008-10-13 18:37:39 PDT
roc -- Did you set the pref for signed.applets.codebase_principal_support?  What platform are you on?
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 19:15:28 PDT
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.
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 21:36:46 PDT
Created attachment 343002 [details] [diff] [review]
fix

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.
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 21:44:46 PDT
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.
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 22:12:59 PDT
Created attachment 343004 [details] [diff] [review]
fix v2

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.
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-13 22:13:37 PDT
Created attachment 343005 [details]
better testcase

Slightly more complete testcase
Comment 9 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-14 01:51:15 PDT
Created attachment 343026 [details] [diff] [review]
fix v3

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?
Comment 10 Vladimir Vukicevic [:vlad] [:vladv] 2008-10-14 10:42:16 PDT
(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.
Comment 11 Mark Smith (:mcs) 2008-10-16 08:38:34 PDT
Created attachment 343402 [details]
Flash project file to build SWF with transparent background
Comment 12 Mark Smith (:mcs) 2008-10-16 08:39:12 PDT
Created attachment 343403 [details]
Flash SWF with transparent background
Comment 13 Kathleen Brade 2008-10-16 08:48:21 PDT
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)".
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-16 20:54:29 PDT
Created attachment 343501 [details] [diff] [review]
fix v4

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!
Comment 15 Ted Mielczarek [:ted.mielczarek] 2008-10-17 03:41:24 PDT
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.
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-17 04:52:22 PDT
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?
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-19 20:36:08 PDT
Created attachment 343860 [details] [diff] [review]
fix v5

There was a change to nsWindow.cpp missing from the last patch.
Comment 18 Dave Townsend [:mossop] 2008-10-22 09:05:25 PDT
*** Bug 461176 has been marked as a duplicate of this bug. ***
Comment 19 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-29 22:29:53 PDT
Pushed 45f2c96d4a9b.

I wonder whether to check in a reftest here.
Comment 20 Doug Halamay 2008-10-30 16:56:51 PDT
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.
Comment 21 Doug Halamay 2008-10-30 17:01:57 PDT
(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.
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-30 18:57:10 PDT
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.
Comment 23 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-30 18:59:31 PDT
Created attachment 345648 [details] [diff] [review]
remove evil

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.
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-02 16:54:53 PST
Checked that in. Doug Halamay, please retest tomorrow with tonight's nightly build. if there's still a bug, please file a new one.
Comment 25 Doug Halamay 2008-11-03 10:29:23 PST
(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

Note You need to log in before you can comment on or make changes to this bug.