Prevent the destruction of WebContents in NavigationThrottle methods

Prevent the destruction of WebContents in NavigationThrottle methods

This CL adds an explicit warning in the NavigationThrottle interface that the
WebContents should remain alive during the execution of the NavigationThrottle
methods. It also postpone the TabClosure in the ExternalNavigationDelegateImpl
on Android, since this methode can be called from the
InterceptNavigationThrottle.

BUG=537634

[clamy, 2015-11-02 17:35:36]

Description was changed from

==========
Prevent the destruction of WebContents in NavigationThrottle methods

This CL adds an explicit warning in the NavigationThrottle interface that the
WebContents should remain alive during the execution of the NavigationThrottle
methods. It also postpone the TabClosure in the ExternalNavigationDelegateImpl
on Android, since this methode can be called from the
InterceptNavigationThrottle.

BUG=537634
==========

to

==========
Prevent the destruction of WebContents in NavigationThrottle methods

This CL adds an explicit warning in the NavigationThrottle interface that the
WebContents should remain alive during the execution of the NavigationThrottle
methods. It also postpone the TabClosure in the ExternalNavigationDelegateImpl
on Android, since this methode can be called from the
InterceptNavigationThrottle.

BUG=537634
==========

[clamy, 2015-11-02 17:35:36]

clamy@chromium.org changed reviewers:
+ nasko@chromium.org

[clamy, 2015-11-02 17:39:02]

@nasko: this what the change would look like, when telling explicitly to the
handle that it was destroyed.

Note: I did not mention it in the meeting, but outside fixing the android code,
there is also the possibility to do the check for the navigation interception
asynchronously. In that case we would return DEFER, post task the check and then
resume/cancel the deferred handle if it is still alive. Main issue with this is
performance of doing a post task instead of a direct return.

[clamy, 2015-11-04 15:43:06]

On 2015/11/02 17:39:02, clamy wrote:
> @nasko: this what the change would look like, when telling explicitly to the
> handle that it was destroyed.
> 
> Note: I did not mention it in the meeting, but outside fixing the android
code,
> there is also the possibility to do the check for the navigation interception
> asynchronously. In that case we would return DEFER, post task the check and
then
> resume/cancel the deferred handle if it is still alive. Main issue with this
is
> performance of doing a post task instead of a direct return.

I did upload a patch that does the check asynchronously at
https://codereview.chromium.org/1414723008/. Let me know what you prefer.

[nasko, 2015-11-06 18:25:11]

On 2015/11/04 15:43:06, clamy wrote:
> On 2015/11/02 17:39:02, clamy wrote:
> > @nasko: this what the change would look like, when telling explicitly to the
> > handle that it was destroyed.
> > 
> > Note: I did not mention it in the meeting, but outside fixing the android
> code,
> > there is also the possibility to do the check for the navigation
interception
> > asynchronously. In that case we would return DEFER, post task the check and
> then
> > resume/cancel the deferred handle if it is still alive. Main issue with this
> is
> > performance of doing a post task instead of a direct return.
> 
> I did upload a patch that does the check asynchronously at
> https://codereview.chromium.org/1414723008/. Let me know what you prefer.

As discussed, I will ignore the CL and it should be closed.