[Webkit-unassigned] [Bug 110743] [WK2] WebPageProxy loadURL() won't work when called just after terminateProcess()

[bugzilla-daemon at webkit.org]

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





--- Comment #1 from Adenilson Cavalcanti Silva <savagobr at yahoo.com>  2013-02-26 12:27:23 PST ---
An update on this issue: I started by moving most of the code in WebPageProxy processDidCrash() to a private function named processTeardown().

It is used by both processDidCrash() and at terminateProcess(). The basic idea here is that when terminateProcess() was called, it should do the cleanup and processDidCrash() should *not* execute in a later step.

Further investigation revealed that WebProcessProxy will call WebPageProxy::processDidCrash() when the connection to WebProcess is closed. So it seems that is required to know  at WebProcessProxy the 2 cases:

a) When WebPageProxy::terminateProcess() has executed: because in this case, we will do the process cleanup just after calling ChildProcesProxy::terminate() and WebPageProxy::processDidCrash() should *not* be executed, otherwise cleanup would be done twice.

and

b) When the process crashed by external factors: in this case no process cleanup has being done so far and *there is* the need to execute WebPageProxy::processDidCrash().

There is an added complication I've observed. Some ports (e.g. EFL) after being notified by WebPageProxy::processDidCrash() that the process has exited, will call WebPageProxy::loadURL(). This happens exactly in the middle of WebProcess associated resources tear down.

I think it makes sense to notify the port of WebProcess unavailability only in cases of real crash, not in the case of explicit termination (i.e. when WebPageProxy::terminateProcess() was called).

Finally, it would be safer to notify the port of WebProcess crash only *after* cleaning up the associated resources (so that if the port calls WebPageProxy::loadURL() or reload(), we wouldn't be in the an undefined state).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.