diff options
| author | xiyuan@chromium.org <xiyuan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-12-22 20:34:42 +0000 |
|---|---|---|
| committer | xiyuan@chromium.org <xiyuan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-12-22 20:34:42 +0000 |
| commit | b5c4ef70068ba850a5b3e6fc494bd2396c9bb1a0 (patch) | |
| tree | fa82bd07b715dc7ee8a9bc16c9569586079aae4f /chrome/worker | |
| parent | 382048328177bcf0b0fe937319fd1b73a132229c (diff) | |
| download | chromium_src-b5c4ef70068ba850a5b3e6fc494bd2396c9bb1a0.zip chromium_src-b5c4ef70068ba850a5b3e6fc494bd2396c9bb1a0.tar.gz chromium_src-b5c4ef70068ba850a5b3e6fc494bd2396c9bb1a0.tar.bz2 | |
Fix racing condition that blocks profiles menu showing up
Chrome should show profiles menu when "enable-udd-profiles" is supplied
on command line. This is broken while refactoring app menu code from
ToolbarView into AppMenuModel. Previously, the profile submenu model is
kept in ToolbarView and profiles menu would show up on 2nd time app menu
showing up. After the refactoring, profile menu is moved into
AppMenuModel, which is re-created everytime before we show app menu. In
AppMenuModel, it requests profiles data from GetProfilesHelper which
will later invoke OnGetProfilesDone. However, app menu is created on the
UI thread and blocks the callback until it shows up. This makes the
profiles mneu empty.
The fix is to leverage an existing profile list in BrowserProcess. When
"enable-udd-profiles" is on, BrowserInit will get the initial profile
list and NewProfileDialog will refresh it if user creates new profile.
And AppMenuModel just use the list to populate the profile menu.
BUG=30417
TEST=Verify profiles menu exists when "enable-udd-profiles" is on command line for issue 30417.
Review URL: http://codereview.chromium.org/503062
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35166 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/worker')
0 files changed, 0 insertions, 0 deletions