Bug 47742 – [GTK] Full page size flash plugins do not show in all situations

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Juan Pablo Ugarte]

Created attachment 70902 [details]
sample app to reproduce bug

I was not able to find the exact problem, but it seems that flash objects the size of the WebKitWebView or bigger do not show up properly.
They start working after you resize the window.

Its easy to reproduce using the test case app and this url.

./a.out http://www.homestarrunner.com/sbemail205.swf


Any ideas?

[Nicolas Dufresne]

(In reply to comment #0) 
> I was not able to find the exact problem, but it seems that flash objects the size of the WebKitWebView or bigger do not show up properly.
> They start working after you resize the window.

I've run this with trunk revison 69781, and I don't see any issues. This was with Flash player 10.1.85.3. Would it be possible to describe more the issue you see and let us know which version of the Flash player you are running ?

[Nicolas Dufresne]

(In reply to comment #1)
> (In reply to comment #0) 
> > I was not able to find the exact problem, but it seems that flash objects the size of the WebKitWebView or bigger do not show up properly.
> > They start working after you resize the window.
> 
> I've run this with trunk revison 69781, and I don't see any issues. This was with Flash player 10.1.85.3. Would it be possible to describe more the issue you see and let us know which version of the Flash player you are running ?

Ok I finally manage to reproduce this bug by moving away from nspluginwrapper. It seems that the widget size allocation does not work very well with the way it is implement right now.

[Nicolas Dufresne]

Created attachment 74388 [details]
Move widget allocation after NPP_SetWindow

This patch moves the plugin widget size allocation after the
NPP_SetWindow is called with the effect that the resize of Flash
content no longer result in grey flash. This seems logical since the
widget tree cannot be fully constructed before the plugin receives
the new container window.

[Adam Barth]

Comment on attachment 74388 [details]
Move widget allocation after NPP_SetWindow

No test?

[Nicolas Dufresne]

(In reply to comment #4)
> (From update of attachment 74388 [details])
> No test?

If you know a way to write a test for this I'd appreciate, but so far those kind of rendering glitches are really hard to automatically test.

I think we may be able to do so by:
1. Creating a window with a fullscreen plugin
2. Scaling down the window
3. Checking that the plugin content is not GTK Theme default color (assuming we have a test plugin that mimics Flash correctly and shows a different color)

The problem is mainly about implementing a plugin that mimic the Adobe's Flash player since we don't really know what it's doing. So far I'm pretty sure they use a GtkDrawingArea, but's that's all I know. So my conclusion is that it's probably possible to test this, but it's very time consuming, which as usual is an issue ;)

Let me know what you think about all this (assuming you have already read the code a little to take in consideration the level of changes involved too).

Note that another way to reproduce this is to Zoom-out pages like youtube.com (assuming you have full zoom enable, and not text zoom).

[Martin Robinson]

(In reply to comment #5)
> (In reply to comment #4)
> > (From update of attachment 74388 [details] [details])
> > No test?
> 
> If you know a way to write a test for this I'd appreciate, but so far those kind of rendering glitches are really hard to automatically test.
> 
> I think we may be able to do so by:
> 1. Creating a window with a fullscreen plugin
> 2. Scaling down the window
> 3. Checking that the plugin content is not GTK Theme default color (assuming we have a test plugin that mimics Flash correctly and shows a different color)

We have pixel dumping support if that will be useful.

[Nicolas Dufresne]

(In reply to comment #6)
> We have pixel dumping support if that will be useful.
I don't think that works with windowed plugin.

[Gustavo Noronha (kov)]

Is this an issue just for windowed plugins? If so, perhaps it would be enough to have a manual test, given the difficulty of testing this in an automated fashion? Check WebCore/manual-tests/, there are plenty of plugin tests in there.

[Nicolas Dufresne]

(In reply to comment #8)
> Is this an issue just for windowed plugins? If so, perhaps it would be enough to have a manual test, given the difficulty of testing this in an automated fashion? Check WebCore/manual-tests/, there are plenty of plugin tests in there.

Yes it's only for windowed plugins. Thanks for the pointer, I'll have a look at those.

[Nicolas Dufresne]

Created attachment 75936 [details]
Patch

[Martin Robinson]

Comment on attachment 75936 [details]
Patch

Okay. I guess this is worth a shot. Thanks for including the test.

[WebKit Commit Bot]

Comment on attachment 75936 [details]
Patch

Clearing flags on attachment: 75936

Committed r73587: <http://trac.webkit.org/changeset/73587>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.