Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from Browser::TabStripEmpty

Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from Browser::TabStripEmpty() (patchset #6 id:100001 of https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from Browser::TabStripEmpty()
>
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
>
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
>
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
>
> See http://crbug.com/616701
>
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701

Committed: https://crrev.com/b59603cd2b5c7b00a47651b57516ef8e802af67b
Cr-Commit-Position: refs/heads/master@{#399164}

[tapted, 2016-06-09 05:58:58]

Created Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask
from Browser::TabStripEmpty()

[tapted, 2016-06-09 05:59:29]

Description was changed from

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> BUG=616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

TBR=rsesek@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=616701
==========

to

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> BUG=616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=616701
==========

[Robert Sesek, 2016-06-09 16:52:08]

lgtm

[tapted, 2016-06-10 12:01:20]

Description was changed from

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> BUG=616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=616701
==========

to

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> See http://crbug.com/616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701
==========

[tapted, 2016-06-10 12:02:40]

Thanks Robert! (note I replaced the BUG= with a link in case it creates
confusion on the bug)

[tapted, 2016-06-10 12:02:48]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2016-06-10 12:03:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2042123005/1

[commit-bot: I haz the power, 2016-06-10 12:40:49]

Description was changed from

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> See http://crbug.com/616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701
==========

to

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> See http://crbug.com/616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701
==========

[commit-bot: I haz the power, 2016-06-10 12:40:50]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-10 12:40:55]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-10 12:42:32]

Description was changed from

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
> 
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
> 
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
> 
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
> 
> See http://crbug.com/616701
> 
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701
==========

to

==========
Revert of Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty() (patchset #6 id:100001 of
https://codereview.chromium.org/2041213002/ )

Reason for revert:
Fix didn't work.

Original issue's description:
> Address a crash under -[NSWindow close] via a WeakPtr PostTask from
Browser::TabStripEmpty()
>
> This is the #1 browser crash for Mac in current Beta - 52.0.2743.24. The
> stacks all have in common a Posted Task that's triggering -[NSWindow
> close] via a base::WeakPtr<Browser>. This only happens via
> Browser::TabStripEmpty().
>
> The WeakPtr is only nerfed when BrowserWindowController's dealloc fully
> completes. It seems plausible that this can be after the NSWindow's
> dealloc fully completes, leading to an invalid access. One would hope
> that [NSWindowController window] returns nil once the controlled window
> is destroyed, but this seems to not be guaranteed.
>
> To (speculatively) fix, set a flag when the controlled window invokes
> -[NSWindowController windowWillClose]. The window shouldn't be accessed
> after this. Ensure the C++ BrowserWindowCocoa shim returns nil in this
> case for the window, even if -[NSWindowController window] doesn't.
>
> See http://crbug.com/616701
>
> Committed: https://crrev.com/7e91932ca0df94f1d3ebe9303e6ff31637751c17
> Cr-Commit-Position: refs/heads/master@{#398474}

# Not skipping CQ checks because original CL landed more than 1 days ago.
See http://crbug.com/616701

Committed: https://crrev.com/b59603cd2b5c7b00a47651b57516ef8e802af67b
Cr-Commit-Position: refs/heads/master@{#399164}
==========

[commit-bot: I haz the power, 2016-06-10 12:42:33]

Patchset 1 (id:??) landed as
https://crrev.com/b59603cd2b5c7b00a47651b57516ef8e802af67b
Cr-Commit-Position: refs/heads/master@{#399164}