summaryrefslogtreecommitdiffstats
path: root/chrome/browser/user_data_manager.cc
Commit message (Collapse)AuthorAgeFilesLines
* Get rid of more calls to FromWStringHack.tony@chromium.org2010-04-261-25/+14
| | | | | | | | | | | BUG=24672 TEST=compiles Patch from Thiago Farina <thiago.farina@gmail.com> Review URL: http://codereview.chromium.org/1750013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45568 0039d316-1c4b-4281-b951-d872f2087c98
* Deprecate file_util::AppendToPath() on non-Windows.evan@chromium.org2010-02-261-6/+11
| | | | | | | | | | | | We still have ~150 callers to AppendToPath in our code, but most of them are in the installer and I'm reluctant to fiddle with that code without having an easy way to test it. BUG=24672 Review URL: http://codereview.chromium.org/654013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40120 0039d316-1c4b-4281-b951-d872f2087c98
* Fix issue 32106xiyuan@chromium.org2010-02-251-5/+19
| | | | | | | | | | | | | | | | | | Issue 32106 happens when user creates a browser window without creating desktop shortcut. In this case, Windows does not have sufficient relaunching info to support pinning the browser window. The fix is to create a shortcut in "User Pinned" folder which Win7 watches and would get relaunch info from it. Also fix a minor bug in win_util::SetAppIdForWindow that would make the function only work for Win7 but not above. BUG=32106 TEST=Verify fix for 32106. See comemnts #1 and #5 for repro steps. Review URL: http://codereview.chromium.org/660038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39963 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Win7 issues for non-default profile:xiyuan@chromium.org2010-01-121-1/+5
| | | | | | | | | | | | | | | | | | | - Fix case A reported by Satoshi.Matsuzaki where a 2nd icon is created on launching chromium in non-default profile. This is because the shortcuts for non-default profile is created with wrong app id. The old use uses user data dir to generate the app id while the GetChromiumAppId expects profile path; - Fix an issue in jump list for non-default profile where the recently close/most visted pages are always opened in the default profile because the underlying shortcuts does not have the correct user-data-dir arguments. BUG=30414 TEST=Verify case A of Satoshi's comments @5 is fixed; Verify the jump list items are opened with correct profile; Review URL: http://codereview.chromium.org/547011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35992 0039d316-1c4b-4281-b951-d872f2087c98
* Append profile info to win7 app id per issue 30414xiyuan@chromium.org2010-01-061-8/+10
| | | | | | | | | | | | | | | | | | | | | Add profile info to app id for non-default profile so that win7 could group chrome icons based on profile. - Add a new chrome/common/win_util.h/cc to hold app id functions that would include profile info for non-default profiles; - Add unit test to the new GetChromiumAppId function; - Browser and JumpList to use the GetChromiumAppId for BrowserWindow and JumpList; - UserDataManager to use it for shortcuts it creates; - Make app id for web apps include profile info as well; - Change web_app::UpdateShortcuts to just update shortcuts description, icon and app id; BUG=30414 TEST=Verify fix for issue 30414. Review URL: http://codereview.chromium.org/506079 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35634 0039d316-1c4b-4281-b951-d872f2087c98
* Fix racing condition that blocks profiles menu showing upxiyuan@chromium.org2009-12-221-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Set prop app id for chromium/application shortcut.xiyuan@chromium.org2009-11-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow up change after andrew's patch for win7 shortcut to properly set app id for chromium/application shortcut. - Move PKEY_AppUserModel_ID and code to set it from app/win_util.cc to base/win_util.cc as SetAppIdForPropertyStore to share with file_util shortcut code; - Add an app_id args to file_util's CreateShortcutLink and UpdateShortcutLink; - Update code that calls the above two function in installer and UserDataManager so that the chromium shortcuts are created with proper app id (except the uninstall shortcut which is not tagged with any app id). - Move ComputeApplicationNameFromURL from Browser to web_app namespace and use it as app id for application shortcut. This makes pinned shortcut and browser window use the same app id and Win7 correctly groups them; - Rename ComputeApplicationNameFromURL to GenerateApplicationNameFromURL per Ben's comments; - Add a DCHECK in SetAppIdForPropertyStore to ensure app id is less than 128 chars and contains no space per msdn; - Change default app id from IDS_PRODUCT_NAME to chrome::kBrowserAppName BUG=28104 TEST=On Win7, pinned shortcut should no longer be separated from running instance of chrome for both chrome and web application. Review URL: http://codereview.chromium.org/399045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32508 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify threading in browser thread by making only ChromeThread deal with ↵jam@chromium.org2009-10-271-7/+4
| | | | | | | | different thread lifetimes.The rest of the code doesn't get MessageLoop pointers since they're not thread-safe and instead just call PostTask on ChromeThread. If the target thread is not alive, then the task is simply deleted.In a followup change, I'll remove any remaining MessageLoop* caching. With this change, there's little to be gained by caching since no locks are involved if the target MessageLoop is guaranteed to outlive the current thread (inferred automatically by the order of the chrome_threads_ array).BUG=25354 Review URL: http://codereview.chromium.org/306032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30163 0039d316-1c4b-4281-b951-d872f2087c98
* Remove deprecated CommandLine(std::wstring) ctor.evan@chromium.org2009-10-261-2/+2
| | | | | | | | | | | Add a ctor for creating a CommandLine for carrying arguments; convert all the users to either that or the FilePath version. BUG=24672 Review URL: http://codereview.chromium.org/329017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30117 0039d316-1c4b-4281-b951-d872f2087c98
* Deprecate PathService::Get(..., wstring*) and use FilePath instead.evan@chromium.org2009-10-191-3/+12
| | | | | | | | | | | | I tried fixing all the Windows code but there's a *ton* of it. This change will at least prevent people from adding new code that uses the deprecated version (as that won't compile on Lin/Mac). BUG=24672 Review URL: http://codereview.chromium.org/293013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29472 0039d316-1c4b-4281-b951-d872f2087c98
* Coverity: Initialize message_loop_ in the constructor.jhawkins@chromium.org2009-09-281-1/+2
| | | | | | | | | CID=1505 BUG=none TEST=none Review URL: http://codereview.chromium.org/219036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27392 0039d316-1c4b-4281-b951-d872f2087c98
* Move l10n_util to app/ben@chromium.org2009-05-051-1/+1
| | | | | | | http://crbug.com/11387 Review URL: http://codereview.chromium.org/109043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15352 0039d316-1c4b-4281-b951-d872f2087c98
* Hide profiles behind a command-line switch since the user-data-dir stuffmunjal@chromium.org2009-02-261-0/+1
| | | | | | | | | | wouldn't work on Mac. See bug http://code.google.com/p/chromium/issues/detail?id=7987 Review URL: http://codereview.chromium.org/28093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10432 0039d316-1c4b-4281-b951-d872f2087c98
* Update include paths for grit files. Go ahead and resorttc@google.com2009-02-221-2/+1
| | | | | | | | the headers too. Review URL: http://codereview.chromium.org/21472 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10167 0039d316-1c4b-4281-b951-d872f2087c98
* Make user_data_manager.cc compile on Posix.jhawkins@chromium.org2009-02-201-16/+18
| | | | | | Review URL: http://codereview.chromium.org/20525 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10074 0039d316-1c4b-4281-b951-d872f2087c98
* I'm relanding the UserDataManager leak fix. I didn't realize we hadsky@google.com2009-01-231-1/+4
| | | | | | | | | | | | | stubs for mac which needed to be updated too. This time I'll wait for the bots to finish compiling before committing. BUG=none TEST=none TBR=munjal Review URL: http://codereview.chromium.org/18566 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8587 0039d316-1c4b-4281-b951-d872f2087c98
* Reverts my user data manager change as it breaks the mac buildbot.sky@google.com2009-01-231-4/+1
| | | | | | | | | | BUG=none TEST=none TBR=munjal Review URL: http://codereview.chromium.org/18564 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8584 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes leak of UserDataManager on shutdown.sky@google.com2009-01-231-1/+4
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/18714 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8581 0039d316-1c4b-4281-b951-d872f2087c98
* Make CommandLine into a normal object, with some statics for getting at the ↵evan@chromium.org2009-01-211-5/+4
| | | | | | | | | | | current process's command line. One explicit goal of this change is to *not* deal with the string/wstring issues at the API on POSIX; the functions are the same as before, which means they remain as broken as before. (I did try to fix the internals, though, so migrating the callers is now possible by adding platform-appropriate hooks.) Review URL: http://codereview.chromium.org/18248 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8347 0039d316-1c4b-4281-b951-d872f2087c98
* Move file enumeration to filepaths.avi@google.com2008-12-111-4/+4
| | | | | | Review URL: http://codereview.chromium.org/13315 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6784 0039d316-1c4b-4281-b951-d872f2087c98
* Chromium-MultiProfile-Prototypemunjal@chromium.org2008-12-031-0/+307
Summary ======= Implement a prototype of multiple profiles in Chrome by utilizing the functionality of user-data-dir command line flag that already exists. A profile in this case is an umbrella for all user data including cookies, history, bookmarks, settings, etc. Each profile gives the user a separation of all these data elements. User Interface ============== - Wrench > "New window in profile" menu item, with sub-menu items. This new menu item has sub menu items for each existing profile, for up to 9 profiles, and one more sub menu item to launch a window in a new profile. The 9 sub-menu items also have the accelerators like CTRL + SHIFT + 1, CTRL + SHIFT + 2, etc. If there are more than 9 profiles, we will also show an extra sub-menu item, "Other...". - New Profile dialog box This dialog box is shown to the use when (s)he clicks Wrench > New window in profile > <New Profile>. It lets the user specify a profile name, and also shows a checkbox to create a desktop shortcut to launch Chrome in that profile. - Choose profile dialog box This dialog box lets the user select a profile from a drop down to open a new window in. It also has an item <New Profile> in the drop down, selecting which will show the new profile dialog box mentioned above. CTRL + M shortcut also launches this dialog box. Code Organization ================= chrome\browser\user_data_dir_profile_manager.h/.cc: This class provides an abstraction of profiles on top of the user data dir command line flag. chrome\browser\views\user_data_dir_new_profile_dialog.h/.cc New profile dialog box code. chrome\browser\views\user_data_dir_profiles_dialog.h/.cc Choose profile dialog box code. Review URL: http://codereview.chromium.org/12895 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6333 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-12 09:00:09 +0000