Closed Bug 458928 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Canvas: 2D, defect, P3)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: Brade, Assigned: roc)

References

Details

(Keywords: fixed1.9.1, mobile)

Attachments

(8 files, 4 obsolete files)

1.44 KB, text/html
Details
1.35 KB, text/html
Details
1.43 KB, text/html
Details
43.50 KB, application/octet-stream
Details
456 bytes, application/x-shockwave-flash
Details
1.51 KB, text/html
Details
19.03 KB, patch
vlad
: review+
Details | Diff | Splinter Review
1.11 KB, patch
jst
: review+
Details | Diff | Splinter Review
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.
Flags: blocking1.9.1?
Keywords: mobile
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).
Assignee: nobody → jmuizelaar
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
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?
Attached file 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.
Attached patch fix (obsolete) — Splinter 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.
Assignee: jmuizelaar → roc
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.
Attached patch fix v2 (obsolete) — Splinter 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.
Attachment #343002 - Attachment is obsolete: true
Attached file better testcase
Slightly more complete testcase
Attached patch fix v3 (obsolete) — Splinter 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?
Attachment #343004 - Attachment is obsolete: true
(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.
(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)".
Attached patch fix v4 (obsolete) — Splinter 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!
Attachment #343026 - Attachment is obsolete: true
Attachment #343501 - Flags: superreview?(jst)
Attachment #343501 - Flags: review?(vladimir)
Blocks: 445595
Blocks: 313462
Blocks: 442109
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?
Attached patch fix v5Splinter Review
There was a change to nsWindow.cpp missing from the last patch.
Attachment #343501 - Attachment is obsolete: true
Attachment #343860 - Flags: superreview?(jst)
Attachment #343860 - Flags: review?(vladimir)
Attachment #343501 - Flags: superreview?(jst)
Attachment #343501 - Flags: review?(vladimir)
Duplicate of this bug: 461176
Attachment #343860 - Flags: superreview?(jst) → superreview+
Pushed 45f2c96d4a9b.

I wonder whether to check in a reftest here.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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.
Attached patch remove evilSplinter 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.
Attachment #345648 - Flags: superreview?(jst)
Attachment #345648 - Flags: review?(jst)
Attachment #345648 - Flags: superreview?(jst)
Attachment #345648 - Flags: superreview+
Attachment #345648 - Flags: review?(jst)
Attachment #345648 - Flags: review+
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
Blocks: 385435
You need to log in before you can comment on or make changes to this bug.