Bug 118650

Summary: Set view to active in ViewClientEfl after WebProcess has relaunched
Product: WebKit Reporter: Sergio Correia (qrwteyrutiyoup) <sergio>
Component: New BugsAssignee: Sergio Correia (qrwteyrutiyoup) <sergio>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, cmarcelo, commit-queue, gyuyoung.kim, luiz, noam, rakuco, tonikitoo, zeno
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Adding WKViewSetIsAtive to ViewClientEfl none

Description Sergio Correia (qrwteyrutiyoup) 2013-07-13 16:38:08 PDT
CoordinatedGraphics: Set scene to active in WebView::paintToCurrentGLContext()
Comment 1 Sergio Correia (qrwteyrutiyoup) 2013-07-13 16:39:49 PDT
Created attachment 206623 [details]
Patch
Comment 2 Sergio Correia (qrwteyrutiyoup) 2013-07-13 16:40:21 PDT
Previously, the scene was set to active in WebView::initialize(), but then
if the Web Process crashed and we needed to recreate the drawing area, via
WebPageProxy::initializeWebPage(), it would create a new scene which would
never be set to active, and from that point on, we would only get a blank
view.

A simple way to verify this behavior on the EFL port would be to kill the
Web Process:

$ killall WebProcess

After this, you will only get a blank view.
Comment 3 Noam Rosenthal 2013-07-14 04:59:57 PDT
Comment on attachment 206623 [details]
Patch

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

> Source/WebKit2/ChangeLog:12
> +        Previously, the scene was set to active in WebView::initialize(), but then
> +        if the Web Process crashed and we needed to recreate the drawing area, via
> +        WebPageProxy::initializeWebPage(), it would create a new scene which would
> +        never be set to active, and from that point on, we would only get a blank
> +        view.

don't we get some kind of event, like didInitialize?
Setting the scene to active during paint doesn't seem like the right solution.

> Source/WebKit2/ChangeLog:19
> +        A simple way to verify this behavior on the EFL port would be to kill the
> +        Web Process:
> +
> +        $ killall WebProcess
> +
> +        After this, you will only get a blank view.

This requires an API test.
Comment 4 Sergio Correia (qrwteyrutiyoup) 2013-07-14 08:07:23 PDT
Thanks for the feedback.

(In reply to comment #3)
> (From update of attachment 206623 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=206623&action=review
> 
> > Source/WebKit2/ChangeLog:12
> > +        Previously, the scene was set to active in WebView::initialize(), but then
> > +        if the Web Process crashed and we needed to recreate the drawing area, via
> > +        WebPageProxy::initializeWebPage(), it would create a new scene which would
> > +        never be set to active, and from that point on, we would only get a blank
> > +        view.
> 
> don't we get some kind of event, like didInitialize?

Apparently not, but I will investigate it further.

> Setting the scene to active during paint doesn't seem like the right solution.
> 

I got the idea from QRawWebView::paint() (UIProcess/API/qt/raw/qrawwebview.cpp:~366), but I agree it feels a bit like a workaround, other than a proper solution. 

> > Source/WebKit2/ChangeLog:19
> > +        A simple way to verify this behavior on the EFL port would be to kill the
> > +        Web Process:
> > +
> > +        $ killall WebProcess
> > +
> > +        After this, you will only get a blank view.
> 
> This requires an API test.

Okay, I will take a look at this as well.
Comment 5 Sergio Correia (qrwteyrutiyoup) 2013-07-29 15:01:17 PDT
@noam: Do you think it would be better to set the view to active in WebView::didRelaunchProcess() [UIProcess/CoordinatedGraphics/WebView.cpp], or should it be done by the clients, such as ViewClientEfl::webProcessDidRelaunch [UIProcess/efl/ViewClientEfl.cpp]? 

The latter seems to be more flexible to ports, since they would be able to choose the behavior they want without interfering with other ports.
Comment 6 Sergio Correia (qrwteyrutiyoup) 2013-08-02 05:11:31 PDT
Created attachment 208004 [details]
Adding WKViewSetIsAtive to ViewClientEfl
Comment 7 Sergio Correia (qrwteyrutiyoup) 2013-08-02 05:12:31 PDT
(In reply to comment #6)
> Created an attachment (id=208004) [details]
> Adding WKViewSetIsAtive to ViewClientEfl

If this patch is okay, I will update the title accordingly.
Comment 8 Build Bot 2013-08-22 15:30:26 PDT
Comment on attachment 208004 [details]
Adding WKViewSetIsAtive to ViewClientEfl

Attachment 208004 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/1526444
Comment 9 WebKit Commit Bot 2013-10-09 13:14:06 PDT
Comment on attachment 208004 [details]
Adding WKViewSetIsAtive to ViewClientEfl

Clearing flags on attachment: 208004

Committed r157178: <http://trac.webkit.org/changeset/157178>
Comment 10 WebKit Commit Bot 2013-10-09 13:14:09 PDT
All reviewed patches have been landed.  Closing bug.