summaryrefslogtreecommitdiffstats
path: root/build/executable.xcconfig
diff options
context:
space:
mode:
authortim@chromium.org <tim@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-01-16 22:46:51 +0000
committertim@chromium.org <tim@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-01-16 22:46:51 +0000
commitc340991948930a82883538e0bd914e669befeb8a (patch)
treecbc542f27fb3a3998b7d9642b48190ec57737406 /build/executable.xcconfig
parentb6ad1cab92ed9e9c1734d1801482cfa8ffd3b4b1 (diff)
downloadchromium_src-c340991948930a82883538e0bd914e669befeb8a.zip
chromium_src-c340991948930a82883538e0bd914e669befeb8a.tar.gz
chromium_src-c340991948930a82883538e0bd914e669befeb8a.tar.bz2
Fix issue 6296 by using a dedicated delegate instance for each infobar that the PasswordManager opens, rather than always using the PasswordManager itself as the delegate.
The crash was occuring because before one infobar completely finished closing (i.e during its close animation), another password infobar would be opened, and for a moment in time two infobars are pointing to the same delegate. When the initial closing animation completes, it would null-out a field (pending_decision_manager_), which the now visible infobar would depend on when the user clicks one of the native buttons. This click would dereference a null member, hence causing the crash. Other clients of infobars seem to be immune to this problem because they either all create dedicated delegate instances per infobar, or they don't reset any state on InfoBarClosed. I think (at the very least) the infobar code should document that it can be risky to use a "shared" delegate due to the possibility of two simultaneously visible infobars referring to the same delegate. Review URL: http://codereview.chromium.org/18065 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8236 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build/executable.xcconfig')
0 files changed, 0 insertions, 0 deletions