Merge 21685 - Relanding r21673 without reenabling the BrowserTest, which appa...

Merge 21685 - Relanding r21673 without reenabling the BrowserTest, which apparently is
still failing.

Make downloads not prevent tabs from closing. If a download creates a
crosssite transition (for example, if you click a link in Gmail that results
in a download in a new tab), that tab will be stuck and you can't close it or
the browser. This is the opposite problem with a similar cause as bug 16246. In
both cases we were using some secondary signal to tell us if we're closing for
a cross site transition or closing the tab, and that signal was wrong. In this
case, we were running the onunload handler, but because there was a pending
RenderViewHost, the RenderManager would think that the close was a crosssite
one, and not forward the close message to actually close the tab. This patch
adds a flag to the on unload handlers that indicates whether it's for a tab
closure or a crosssite transition, so we can do the right thing unambiguously
when the message returns. In this case I keep this information in the
RenderView in case we send multiple close requests, we'll close the tab if any
of them were for the entire tab, even if that particular one was dropped
because we don't want to have more than one in flight at once. BUG=17560
TEST=none.
Review URL: http://codereview.chromium.org/160122
Review URL: http://codereview.chromium.org/159426

TBR=brettw@chromium.org


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=21806

[brettw, 2009-07-28 03:01:58]

LGTM

On Mon, Jul 27, 2009 at 7:48 PM, <laforge@chromium.org> wrote:
> Reviewers: brettw,
>
> Description:
> Merge 21685 - Relanding r21673 without reenabling the BrowserTest, which
> apparently is
> still failing.
>
> Make downloads not prevent tabs from closing. If a download creates a
> crosssite transition (for example, if you click a link in Gmail that
> results
> in a download in a new tab), that tab will be stuck and you can't close
> it or
> the browser. This is the opposite problem with a similar cause as bug
> 16246. In
> both cases we were using some secondary signal to tell us if we're
> closing for
> a cross site transition or closing the tab, and that signal was wrong.
> In this
> case, we were running the onunload handler, but because there was a
> pending
> RenderViewHost, the RenderManager would think that the close was a
> crosssite
> one, and not forward the close message to actually close the tab. This
> patch
> adds a flag to the on unload handlers that indicates whether it's for a
> tab
> closure or a crosssite transition, so we can do the right thing
> unambiguously
> when the message returns. In this case I keep this information in the
> RenderView in case we send multiple close requests, we'll close the tab
> if any
> of them were for the entire tab, even if that particular one was dropped
> because we don't want to have more than one in flight at once. BUG=3D1756=
0
> TEST=3Dnone.
> Review URL: http://codereview.chromium.org/160122
> Review URL: http://codereview.chromium.org/159426
>
> TBR=3Dbrettw@chromium.org
>
>
> Please review this at http://codereview.chromium.org/160249
>
> SVN Base: svn://chrome-svn/chrome/branches/195/src/
>
> Affected files:
> =A0MM =A0 =A0chrome/browser/browser.cc
> =A0MM =A0 =A0chrome/browser/renderer_host/render_view_host.h
> =A0MM =A0 =A0chrome/browser/renderer_host/render_view_host.cc
> =A0MM =A0 =A0chrome/browser/renderer_host/render_view_host_delegate.h
> =A0MM =A0 =A0chrome/browser/tab_contents/render_view_host_manager.h
> =A0MM =A0 =A0chrome/browser/tab_contents/render_view_host_manager.cc
> =A0MM =A0 =A0chrome/browser/tab_contents/tab_contents.h
> =A0MM =A0 =A0chrome/browser/tab_contents/tab_contents.cc
>
>
>