Bug 98789 - [GTK] Plugin don't display
Summary: [GTK] Plugin don't display
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 98860
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-09 10:10 PDT by Daniel Drake
Modified: 2012-10-10 00:39 PDT (History)
4 users (show)

See Also:


Attachments
Patch (1.67 KB, patch)
2012-10-09 12:58 PDT, Daniel Drake
no flags Details | Formatted Diff | Diff
Patch (3.41 KB, patch)
2012-10-09 15:29 PDT, Daniel Drake
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Drake 2012-10-09 10:10:30 PDT
Since webkitgtk-1.9.90, plugins don't display properly.

Testing <embed src="foo.ogg" width="100" height="100" /> with totem-mozplugin installed to handle such requests, using GtkLauncher.

Reproduced on systems with and without OpenGL support available.

When the page is loaded, the audio starts playing, but the video can't be seen - its all white. Moving the window around the screen doesn't cause any change. Maximizing the window causes the video to suddenly appear.

Tracked this down; the regression was introduced by r126182 in bug #90085.
Comment 1 Martin Robinson 2012-10-09 10:18:45 PDT
I can't test plugins easily, but could you check if removing the early-return in webkit_web_view_size_allocate fixes the issue?
Comment 2 Daniel Drake 2012-10-09 10:37:07 PDT
Thanks for the fast response. Commenting out the first return statement in webkit_web_view_size_allocate() (as follows) avoids the issue.

    if (allocation->width == oldAllocation.width && allocation->height == oldAllocation.height)
        /*return*/;
Comment 3 Martin Robinson 2012-10-09 10:40:31 PDT
Do you mind writing a patch that takes the same approach as webkitWebViewBaseSizeAllocate from ~/WebKit/Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp?
Comment 4 Carlos Garcia Campos 2012-10-09 10:45:02 PDT
This is probably because you always have to allocate the children in size allocate. You can probably still avoid resizing the frame view if the size hasn't changed, but even if the size it's the same, the coords might have changed, so children need to be allocated.
Comment 5 Daniel Drake 2012-10-09 12:58:15 PDT
Created attachment 167828 [details]
Patch
Comment 6 Martin Robinson 2012-10-09 13:05:14 PDT
Comment on attachment 167828 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=167828&action=review

> Source/WebKit/gtk/webkit/webkitwebview.cpp:-875
> -    gtk_widget_get_allocation(widget, &oldAllocation);
> -
>      GTK_WIDGET_CLASS(webkit_web_view_parent_class)->size_allocate(widget, allocation);
> -    if (allocation->width == oldAllocation.width && allocation->height == oldAllocation.height)
> -        return;

I think this is the wrong fix. Instead of simply ignoring whether or not the size has changed, you should pass the information to resizeWebViewFromAllocation and only keep the call to gtk_container_forall(GTK_CONTAINER(webView), updateChildAllocationFromPendingAllocation, 0); when the size hasn't changed. Please see the WebKitWebViewBase for an example.
Comment 7 Daniel Drake 2012-10-09 15:29:27 PDT
Created attachment 167861 [details]
Patch
Comment 8 WebKit Review Bot 2012-10-09 19:11:34 PDT
Comment on attachment 167861 [details]
Patch

Clearing flags on attachment: 167861

Committed r130838: <http://trac.webkit.org/changeset/130838>
Comment 9 WebKit Review Bot 2012-10-09 19:11:38 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 WebKit Review Bot 2012-10-09 23:00:35 PDT
Re-opened since this is blocked by bug 98860
Comment 11 Zan Dobersek 2012-10-09 23:43:32 PDT
(In reply to comment #10)
> Re-opened since this is blocked by bug 98860

Sigh ... The rollout didn't help, the crashes are still there. Sorry for all the noise, I'll get this patch back into the tree.
Comment 12 Zan Dobersek 2012-10-10 00:39:46 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > Re-opened since this is blocked by bug 98860
> 
> Sigh ... The rollout didn't help, the crashes are still there. Sorry for all the noise, I'll get this patch back into the tree.

Rolled back in in r130867.
http://trac.webkit.org/changeset/130867