summaryrefslogtreecommitdiffstats
path: root/webkit
diff options
context:
space:
mode:
authorcpu@chromium.org <cpu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-03-08 00:39:29 +0000
committercpu@chromium.org <cpu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-03-08 00:39:29 +0000
commit54430e2fa0e3ca05a4dfed41aaf6f1e2bd4ee307 (patch)
tree3c6c85bab3d22f02eee11d5d7a4c24750beff83d /webkit
parent28e9bb85d5575e27dc8d527675d34cb1af2e73c5 (diff)
downloadchromium_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