Make DoDeferredClose a non-nestable task

Make DoDeferredClose a non-nestable task

This makes it behave the same as the Close function.

Destroying RenderWidgetCompositor during RenderWidget::DoDeferredClose
can cause problems for nested message loops.  The bug is that
InputHandlerProxy creates a SwapPromiseMonitor which adds itself to the
LayerTreeHost.  In that stack, a nested message loop is run which runs
the RenderWidget::DoDeferredClose function which previously destroyed
the LayerTreeHost.  This explodes, because LayerTreeHost expects all
SwapPromiseMonitors to be removed before it is destroyed.

Making DoDeferredClose non-nestable avoids this problem, as the nested
message loop can't run the task, the SwapPromiseMonitor safely gets
removed, and then the LayerTreeHost can be cleanly deleted.

This patch depends on https://codereview.chromium.org/512533002

[email protected],[email protected]
BUG=403500
Committed: https://crrev.com/7c132d2e67ce5ebc5d32df5994028f4a419217db
Cr-Commit-Position: refs/heads/master@{#292668}

[enne (OOO), 2014-08-26 21:41:08]

An alternative to https://codereview.chromium.org/504373002/

[jamesr, 2014-08-26 21:42:01]

[email protected] changed reviewers:
+ [email protected]

[jamesr, 2014-08-26 21:42:01]

I think this makes sense.  +darin to double check

[danakj, 2014-08-26 21:44:08]

Can you still make the CHECK into a DCHECK in ~cc::LTH?

[enne (OOO), 2014-08-26 21:44:42]

On 2014/08/26 at 21:44:08, danakj wrote:
> Can you still make the CHECK into a DCHECK in ~cc::LTH?

Why? That seems pretty serious.

[danakj, 2014-08-26 21:46:08]

On 2014/08/26 21:44:42, enne wrote:
> On 2014/08/26 at 21:44:08, danakj wrote:
> > Can you still make the CHECK into a DCHECK in ~cc::LTH?
> 
> Why? That seems pretty serious.

Cuz we added it to find this bug, now that it's resolved, DCHECK should be
sufficient? Same argument as all other DCHECKs vs CHECKs, it's a waste of the
release binary.

[enne (OOO), 2014-08-26 21:53:52]

On 2014/08/26 at 21:46:08, danakj wrote:
> On 2014/08/26 21:44:42, enne wrote:
> > On 2014/08/26 at 21:44:08, danakj wrote:
> > > Can you still make the CHECK into a DCHECK in ~cc::LTH?
> > 
> > Why? That seems pretty serious.
> 
> Cuz we added it to find this bug, now that it's resolved, DCHECK should be
sufficient? Same argument as all other DCHECKs vs CHECKs, it's a waste of the
release binary.

Done.  Sorry, was not aware of that history.  I was looking at this in
http://crbug.com/407090 and not http://crbug.com/403500, which it turns out are
the same thing.

[enne (OOO), 2014-08-28 18:21:33]

darin: ping

[darin (slow to review), 2014-08-29 17:17:08]

https://codereview.chromium.org/513433002/diff/40001/content/renderer/render_...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/513433002/diff/40001/content/renderer/render_...
content/renderer/render_widget.cc:1419:
base::MessageLoop::current()->PostNonNestableTask(
I suppose it is possible that this may cause problems for
window.showModalDialog(), but I don't care about breaking that. LGTM.

[enne (OOO), 2014-08-29 17:24:07]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-08-29 17:25:36]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/[email protected]/513433002/40001

[commit-bot: I haz the power, 2014-08-29 18:22:20]

Committed patchset #3 (id:40001) as bf1ed5c509a49e42c33fdc4c92f55812d1e732b3

[commit-bot: I haz the power, 2014-09-10 03:10:00]

Patchset 3 (id:??) landed as
https://crrev.com/7c132d2e67ce5ebc5d32df5994028f4a419217db
Cr-Commit-Position: refs/heads/master@{#292668}