Bug 52349 – [GTK] WebkitGTK doesn't paint Flash content until window resized

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Kristianto]

Created attachment 78775 [details]
Program produce bug

Overview:
Flash content doesn't appear when default window size is equal or lower than flash content size.

Step to Reproduce:
Embed a flash content and set window size lower than or equals to flash content size.

e.g flash content 800x600, window size <= 800x600
embed using html tag and swfobject produce the same result

Actual Results:
Flash content doesn't appear after window loaded, there is just a blank grey window, until I resize the window to somewhat much bigger size then flash content painted normally.

Expected Results:
Flash content painted after window loaded.

Build 2011-01-13 on Fedora 13 i686

Thanks

[Nicolas Dufresne]

This looks like bug https://bugs.webkit.org/show_bug.cgi?id=47742 which is supposed to be fixed. A manual test exist in the tree, see Source/WebCore/manual-tests/plugins/gtk-windowed-grey-glitch.html

I just ran your test program on FC14, WebKitGTK 1.3.6 and also a recent build of WebKit trunk I've build myself and I don't see the bug you are reporting. Are you sure your not running your test with WebKit shipped with FC13 (which does not contain the fix). To check used ldd on your program and make sure the libwebkitgtk.so is the right one.

Also, the version of Flash I'm running is native 64bit 1,2,161,23

[Kristianto]

Yes, I used webkitgtk shipped with FC13, I also compile and install webkitgtk1.2.6. I will try to compile with webkitgtk1.3.6 tomorrow. Sorry for re-reporting this already reported bug.

Thanks

[Martin Robinson]

Seems to be working with a recent version of WebKitGTK+. Going to close this one, but feel free to reopen if you can reproduce it with > 1.3.11 or so.

[Thierry Reding]

(In reply to comment #3)
> Seems to be working with a recent version of WebKitGTK+. Going to close this
> one, but feel free to reopen if you can reproduce it with > 1.3.11 or so.

I'm not sure if the bug is exactly the same but I see a very similar issue. I
build latest WebKit with the following options:

../configure --disable-silent-rules --disable-geolocation --disable-spellcheck --with-unicode-backend=glib --disable-video --disable-accelerated-compositing --with-acceleration-backend=none --disable-webgl --disable-webkit2 --with-gtk=2.0

When I run the resulting GtkLauncher on Youtube, everytime I want to play a
video the plugin area remains black. Note that the video is actually playing
because I can hear the corresponding audio. After resizing the window the
content is immediately visible. I can reproduce this with 1.10.0 and any of
the 1.9.x releases as well and 1.8.0 also had the same issue. Note that it
doesn't happen with the Gtk+ 3.0 backend, which I unfortunately cannot use
because Flash content plays back way too slow.

[Thierry Reding]

I also just tried the manual test introduced to verify the following bug:

https://bugs.webkit.org/show_bug.cgi?id=47742

and saw that it fails. When resizing the window, the page is painted grey
when the window is enlarged. Shrinking works properly.

[Thierry Reding]

(In reply to comment #5)
> I also just tried the manual test introduced to verify the following bug:
> 
> https://bugs.webkit.org/show_bug.cgi?id=47742
> 
> and saw that it fails. When resizing the window, the page is painted grey
> when the window is enlarged. Shrinking works properly.

I think I found the culprit. Both problems that I've described go away if I
revert 102604 (some manual resolution of conflicts is required). I work from
the mirrored WebKit.git repository where the commit's SHA1 is:

  252af0d87ef150343b939a19522d84f63d6ed9d5

[Martin Robinson]

Perhaps what's necessary is to call gtk_widget_queue_resize somewhere?

[Nicolas Dufresne]

(In reply to comment #7)
> Perhaps what's necessary is to call gtk_widget_queue_resize somewhere?

I would have to have a look at this patch more closely. But I feel like that change cause the resize to be sent before the Flash plugin has the window (NPP_SetWindow being called iirc). Which bring back the old issue that the plugin never redraw.

[Martin Robinson]

(In reply to comment #8)
> (In reply to comment #7)
> > Perhaps what's necessary is to call gtk_widget_queue_resize somewhere?
> 
> I would have to have a look at this patch more closely. But I feel like that change cause the resize to be sent before the Flash plugin has the window (NPP_SetWindow being called iirc). Which bring back the old issue that the plugin never redraw.

So perhaps once SetWindow is called, we should queue another widget resize and add a delayed allocation to the plugin.