This is easy to reproduce undocking the inspector:
1- Run MiniBrowser with WEBKIT_FORCE_COMPOSITING_MODE=1
2- Open the inspector
3- Click on undock button
The new window is created and the view is moved there but nothing is rendered. you need to force a redraw, by resizing the window, for example, to see the contents. This also happen when using the threaded compositor, since compositing mode is always enabled too.
Created attachment 281167 [details]
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Does this fix the similar bug that occurs when resizing the window?
(In reply to comment #3)
> Does this fix the similar bug that occurs when resizing the window?
I don't know I haven't noticed that. Do you mean when resizing the window with the threaded compositor or without it but compositing mode forced?
(In reply to comment #4)
> (In reply to comment #3)
> > Does this fix the similar bug that occurs when resizing the window?
> I don't know I haven't noticed that. Do you mean when resizing the window
> with the threaded compositor or without it but compositing mode forced?
With compositing mode, without threaded compositor... but actually, I can't reproduce it anymore. Let's forget about it for now; maybe it got fixed at some point.
Comment on attachment 281167 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=281167&action=review
(I think Zan would be a better reviewer for this.)
> + mode when the view is unrealized, because the native surface handle por compositing is destroyed, but it doesn't
> + not. The Web process never exits accelerated mode when compositing mode is forzed, but the UI process doesn't
Created attachment 281337 [details]
Previous patch broke the build with redirected X window disabled because of a wrong ifdef.
Comment on attachment 281337 [details]
Committed r202273: <http://trac.webkit.org/changeset/202273>