458928 - drawWindow() does not render Flash content when scale is not 100%

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P3)

Description

[Kathleen :Brade]

Attachment: 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] (needinfo me, slow to respond)]

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)]

None of these testcases work for me at all.

Comment 3

[Kathleen :Brade]

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)]

Attachment: 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)]

Attachment: 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)]

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)]

Attachment: 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)]

Attachment: better testcase

Slightly more complete testcase

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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] (needinfo me, slow to respond)]

(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]]

Attachment: Flash project file to build SWF with transparent background

Comment 12

[Mark Smith [:mcs]]

Attachment: Flash SWF with transparent background

Comment 13

[Kathleen :Brade]

Attachment: 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)]

Attachment: 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

[(not currently active) Ted Mielczarek]

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)]

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)]

Attachment: fix v5

There was a change to nsWindow.cpp missing from the last patch.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed 45f2c96d4a9b.

I wonder whether to check in a reftest here.

Comment 20

[Doug Halamay]

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]

(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)]

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)]

Attachment: 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)]

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]

(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