Bug 159512 - [GTK] White page when loaded tab is visited until it's hovered when AC mode is always on
Summary: [GTK] White page when loaded tab is visited until it's hovered when AC mode i...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
: 155572 (view as bug list)
Depends on: 159455
Blocks: 154066
  Show dependency treegraph
 
Reported: 2016-07-07 08:30 PDT by Carlos Garcia Campos
Modified: 2016-07-21 00:36 PDT (History)
4 users (show)

See Also:


Attachments
Patch (7.78 KB, patch)
2016-07-19 03:00 PDT, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (6.22 KB, patch)
2016-07-19 03:39 PDT, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2016-07-07 08:30:42 PDT
This happens in ephy at startup when restoring tabs from a previous session. Tabs that are loaded in the background, are fully white when visited the first time, until a redrawn is forced, for example, moving the mouse over the view, or resizing the window. It doesn't always happen, so it looks like a sync issue between web and ui processes. When using the threaded compositor it happens more often. When AC is not forced to be always enabled, it never happens. It happens with 2.12 branch too, so it's not a recent regression, I think it has always happened.
Comment 1 Carlos Garcia Campos 2016-07-08 03:39:28 PDT
The problem is that for some reason we are failing to pre-render pages, so even if drawing area schedules renderings before the widget is mapped, only the white background is rendered by the web process, so that's what we render on map. In non-compositing mode we have the page correctly pre-rendered in a bitmap image, ready to be rendered on map.
Comment 2 Carlos Garcia Campos 2016-07-08 04:30:36 PDT
Something similar happens when not using the redirected x window, so it's doesn't seem to be a problem of the redirected window.
Comment 3 Carlos Garcia Campos 2016-07-15 01:52:33 PDT
With the patch attached to bug #159803 we can reproduce this issue using MiniBrowser:

1 - Open MiniBrowser with AC mode forced, and several tabs:

WEBKIT_FORCE_COMPOSITING_MODE=1 bin/MiniBrowser http://www.webkitgtk.org http://www.igalia.com http://www.gnome.org

You can use any websites, but it's important that the sites don't have animations or anything that requires accelerated compositing.

2 - Wait until all tabs are loaded.

3 - Visit the secondary tabs, by clicking on the tab and without moving the mouse out of the tab.

Most of the times, the first time tabs are visited, web view is just full white, when moving the mouse over the view, or visiting it again, the actual contents appear.
Comment 4 Carlos Garcia Campos 2016-07-19 02:29:45 PDT
*** Bug 155572 has been marked as a duplicate of this bug. ***
Comment 5 Carlos Garcia Campos 2016-07-19 03:00:40 PDT
Created attachment 283989 [details]
Patch
Comment 6 Carlos Garcia Campos 2016-07-19 03:01:21 PDT
This depends on patch attached to bug #159455
Comment 7 Carlos Garcia Campos 2016-07-19 03:39:11 PDT
Created attachment 283990 [details]
Patch
Comment 8 Michael Catanzaro 2016-07-20 17:43:20 PDT
Comment on attachment 283990 [details]
Patch

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

> Source/WebKit2/ChangeLog:15
> +        initialize to avoid artifacts when the web process hasn't render anyting yet. That initialization is actually

rendered anything
Comment 9 Carlos Garcia Campos 2016-07-21 00:36:57 PDT
Committed r203500: <http://trac.webkit.org/changeset/203500>