diff options
| author | tim@chromium.org <tim@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-12-16 20:58:02 +0000 |
|---|---|---|
| committer | tim@chromium.org <tim@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-12-16 20:58:02 +0000 |
| commit | 3eece06ea813d3fd7d3e29fca307ee34e469d575 (patch) | |
| tree | cee5d810a89913a4cc2670624948380e1de2390d /DEPS | |
| parent | 770137a4b5bd380a054eaf289abcf019e2337401 (diff) | |
| download | chromium_src-3eece06ea813d3fd7d3e29fca307ee34e469d575.zip chromium_src-3eece06ea813d3fd7d3e29fca307ee34e469d575.tar.gz chromium_src-3eece06ea813d3fd7d3e29fca307ee34e469d575.tar.bz2 | |
Fix for crbug.com/5471 (browser crash regression).
The "pending_save_manager_" used to only be non-null
between the time the user hits 'Submit' on a form and we either 1) show an
infobar, or 2) update an existing login. Now, instead, the member only gets reset on
InfoBarClosed(), and so this ordering of events was causing a crash:
--ExpireInfoBar, removes delegate from infobar_delegates_
--WebContents::DidStopLoading, causes PasswordManager to call AddInfoBar because it
has a pending_save_manager_ (and AddInfoBar succeeds because there is no "equal"
delegate already in the set)
--Animation terminates, which calls InfoBarClosed(), and resets the
pending_save_manager_
--Now we have an infobar and a null pending_save_manager_, so clicking Accept/Cancel
will deref 0.
Renamed |pending_save_manager_| to |provisional_save_manager_| to be more consistent,
and added |pending_decision_manager_| to take responsibility of the PasswordFormManager
in |provisional_save_manager_| when the infobar comes in to play, so that we have
the same ownership model as before the new infobar changes.
Review URL: http://codereview.chromium.org/14464
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7094 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'DEPS')
0 files changed, 0 insertions, 0 deletions