diff options
author | cpu@chromium.org <cpu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-03-08 00:39:29 +0000 |
---|---|---|
committer | cpu@chromium.org <cpu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-03-08 00:39:29 +0000 |
commit | 54430e2fa0e3ca05a4dfed41aaf6f1e2bd4ee307 (patch) | |
tree | 3c6c85bab3d22f02eee11d5d7a4c24750beff83d /webkit | |
parent | 28e9bb85d5575e27dc8d527675d34cb1af2e73c5 (diff) | |
download | chromium_src-54430e2fa0e3ca05a4dfed41aaf6f1e2bd4ee307.zip chromium_src-54430e2fa0e3ca05a4dfed41aaf6f1e2bd4ee307.tar.gz chromium_src-54430e2fa0e3ca05a4dfed41aaf6f1e2bd4ee307.tar.bz2 |
Make the toast more reliable and less dangerous
The current toast (re-activation) experiment suffers from the following problems:
1- False negative: the toast can be triggered even if chrome is being used
2- Nested message loop crash: If chrome tries to run while the toast is being shown, it crashes
This change addresses both conditions. Before running the toast we leverage the
process_singleton to detect another instance. If so we abort with "no thanks".
When showing the toast and its nested message loop we take the process_singleton lock which
inhibits dispatch of the wm_copydata message which spawns new tabs in the current process if
we try to span a new tab while in the nested message loop we crash.
BUG=32026
TES=see bug
Review URL: http://codereview.chromium.org/6625037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@77214 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit')
0 files changed, 0 insertions, 0 deletions