Don't leave renderer process frozen when canceling JavaScript dialogs.

Don't leave renderer process frozen when canceling JavaScript dialogs.

This involves:
1. Canceling dialogs before a process swap, to unblock the old renderer.
2. Running the callback when canceling the dialog.

BUG=297289
TEST=Cross-process navigation can commit while dialog is showing.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=226309

[Charlie Reis, 2013-10-01 02:58:06]

Avi, here's a second attempt at https://codereview.chromium.org/24436003, which
had memory errors.

Parts 1 and 2 are necessary (canceling dialogs on process swaps and running the
callback).

Part 3 is just me being cautious, just in case there are other ways that
RenderViewHosts could be deleted that I'm not aware of.  It's a little awkward
to make JavaScriptAppModalDialog a WebContentsObserver (since it already
inherits a web_contents() method from AppModalDialog), but it does feel a bit
safer.  I'm open to opinions on that one.

[Avi (use Gerrit), 2013-10-01 03:20:18]

https://codereview.chromium.org/25434002/diff/2001/chrome/browser/ui/app_moda...
File chrome/browser/ui/app_modal_dialogs/javascript_app_modal_dialog.cc (right):

https://codereview.chromium.org/25434002/diff/2001/chrome/browser/ui/app_moda...
chrome/browser/ui/app_modal_dialogs/javascript_app_modal_dialog.cc:121: void
JavaScriptAppModalDialog::RenderViewDeleted(
This really, really makes me sad. The old JavaScript dialog code knew all about
its callers and had a million hooks into them, and this smells of those days.

The WebContentsImpl knows when things are shifting around. Can't it do a better
job of cancelling the dialog if the RVH changes?

[Charlie Reis, 2013-10-01 16:39:29]

PTAL.

https://codereview.chromium.org/25434002/diff/2001/chrome/browser/ui/app_moda...
File chrome/browser/ui/app_modal_dialogs/javascript_app_modal_dialog.cc (right):

https://codereview.chromium.org/25434002/diff/2001/chrome/browser/ui/app_moda...
chrome/browser/ui/app_modal_dialogs/javascript_app_modal_dialog.cc:121: void
JavaScriptAppModalDialog::RenderViewDeleted(
On 2013/10/01 03:20:18, Avi wrote:
> This really, really makes me sad. The old JavaScript dialog code knew all
about
> its callers and had a million hooks into them, and this smells of those days.
> 
> The WebContentsImpl knows when things are shifting around. Can't it do a
better
> job of cancelling the dialog if the RVH changes?

That part was optional.  The new WebContents method I added handles all the ways
of the RVH disappearing that I know of, so I went ahead and deleted the
WebContentsObserver stuff here.

[Avi (use Gerrit), 2013-10-01 17:08:36]

lgtm

I'm cool with this. Thanks.

[Charlie Reis, 2013-10-01 17:09:58]

Thanks.  +sky for OWNERS.

[sky, 2013-10-01 17:58:58]

LGTM

[commit-bot: I haz the power, 2013-10-01 18:01:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/creis@chromium.org/25434002/12001

[commit-bot: I haz the power, 2013-10-01 21:39:03]

Change committed as 226309