summaryrefslogtreecommitdiffstats
path: root/chrome/browser/process_singleton_win.cc
Commit message (Collapse)AuthorAgeFilesLines
* Properly add --original-process-start-time for browser rendezvous.koz@chromium.org2013-05-241-7/+7
| | | | | | | | BUG=242031 Review URL: https://chromiumcodereview.appspot.com/15789003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@202032 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor BrowserProcessPlatformPart.gab@chromium.org2013-05-201-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous design was to have a class, BrowserProcessPlatformPart, which has various implementations for specific platforms and a common implementation for all other platforms. These implementations (e.g., browser_process_platform_part_(chromeos|aurawin).h) both implement the common methods defined in the common implementation (browser_process_platform_part.h) and some methods specific to their platform. The main problem with this design is that each custom implementation needs to re-implement the default behavior even for the methods for which the base implementation would have been fine (since it's a compile-time choice and doesn't use inheritance). This will become worst as more common methods get added to the base BrowserProcessPlatformPart, forcing every custom implementation to provide a copy of the default implementation for that method... The previous design also forces ugly #if ... #elif ... #elif ... #else ...#endif style of includes just to use the common methods since all headers, but one, are discarded by gyp. This will become worst as more platforms need custom BrowserProcessPlatformPart. Both scenarios making this worst are happening as part of addressing https://codereview.chromium.org/14576015/diff/43017/chrome/browser/lifetime/application_lifetime.cc#newcode116 where adding a common call to BrowserProcessPlatformPart and using it to get rid of the ifdefs there implies one more common call and 2 more platforms. With the new design: There is a common base class which platform-specific implementation override as desired. The #ifdef include-mess is dealt with by having a meta-include in browser_process_platform_part.h which knows which impl to include at compile-time. This is a precursor CL to https://codereview.chromium.org/14576015 BUG=235648, 232842, 179830 Review URL: https://chromiumcodereview.appspot.com/14951007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201028 0039d316-1c4b-4281-b951-d872f2087c98
* Move winaura specific methods and members from ↵gab@chromium.org2013-05-171-1/+7
| | | | | | | | | | | | | | | | | | | chrome/browser/browser_process.h to chrome/browser/browser_process_platform_part_winaura.h Precursor CL to https://codereview.chromium.org/14576015/ BUG=235648, 232842, 179830 Originally Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=200576 Reverted: http://crrev.com/200656 The cause of the issue is that the current paradigm is such that you can still include the header from the base class although the base class is ruled out in gyp... this resulted in a Heap Corruption debug check when deleting the TestingBrowserProcessPlatformPart on WinAura since it would take its definition from browser_process_platform_part.h at compile time, but use the impl from browser_process_platform_part_aurawin.h at runtime... This paradigm is being fixed in https://codereview.chromium.org/14951007/ and thus simply #ifdefing the right definition in testing_browser_process_platform_part.h for now is fine. Review URL: https://chromiumcodereview.appspot.com/14698027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@200926 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 200576 "Move winaura specific methods and members from ch..."rouslan@chromium.org2013-05-161-7/+1
| | | | | | | | | | | | | | | | | | | This is a speculative revert to address all interactive_ui_tests and browser_tests timing out on win_aura. > Move winaura specific methods and members from chrome/browser/browser_process.h to chrome/browser/browser_process_platform_part_winaura.h > > Precursor CL to https://codereview.chromium.org/14576015/ > > BUG=235648, 232842, 179830 > > Review URL: https://chromiumcodereview.appspot.com/14698027 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/14828010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@200656 0039d316-1c4b-4281-b951-d872f2087c98
* Move winaura specific methods and members from ↵gab@chromium.org2013-05-161-1/+7
| | | | | | | | | | | | chrome/browser/browser_process.h to chrome/browser/browser_process_platform_part_winaura.h Precursor CL to https://codereview.chromium.org/14576015/ BUG=235648, 232842, 179830 Review URL: https://chromiumcodereview.appspot.com/14698027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@200576 0039d316-1c4b-4281-b951-d872f2087c98
* Add UMA tracking for warm start time.koz@chromium.org2013-05-131-0/+9
| | | | | | | | | | | | | This adds UMA tracking for Startup.WarmStartTimeFromRemoteProcessStart, which is the time between when a chrome process starts and when it successfully notifies an already running process of its existence. BUG=238591 R=cpu@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/15021013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199655 0039d316-1c4b-4281-b951-d872f2087c98
* IsMachineATablet is now modified to check only for touch capability and ↵shrikant@chromium.org2013-04-241-5/+9
| | | | | | | | | | | | | hence name change as well. Also added minor modification of checking viewer connection process for immersive mode. BUG=223778 TEST=none Review URL: https://chromiumcodereview.appspot.com/14061007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196242 0039d316-1c4b-4281-b951-d872f2087c98
* Extract locking behaviour from ProcessSingleton.erikwright@chromium.org2013-04-191-28/+1
| | | | | | | | | | | | | | | | | This refactoring continues the division of the behaviour of ProcessSingleton into two parts: * The protocol for establishing a server process and communicating between the client and server. * How the server processes command-line invocations. Very small behavioural change: * If an error occurs while parsing the command-line received via COPY_DATA, the modal dialog (if any) is no longer flashed and raised to foreground. The motivation for this change is that I wish to introduce some more sophisticated behaviour when queuing messages during startup. See the follow-up CL (in-progress) at https://codereview.chromium.org/12674028/ . BUG=170726,170734,225693 Review URL: https://chromiumcodereview.appspot.com/12096114 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@195264 0039d316-1c4b-4281-b951-d872f2087c98
* Add tests that cover the behaviour of ProcessSingleton during startup.erikwright@chromium.org2013-04-031-1/+5
| | | | | | | | | | R=robertshield@chromium.org BUG=170726, 170734 Review URL: https://chromiumcodereview.appspot.com/12594039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@192136 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a bug wherein a member method masked a windows API call.erikwright@chromium.org2013-03-281-51/+52
| | | | | | | | | | | | ProcessSingleton is supposed to flash/bring to the foreground the visible modal dialog in response to a new execution of chrome.exe. I verified that the functionality was broken by calling chrome.exe --try-chrome-again=0, sending the toast to the background, and then launching chrome.exe again. Before this CL, nothing happens. After this CL, the toast pops to the foreground. R=thakis@chromium.org BUG=None Review URL: https://chromiumcodereview.appspot.com/12918031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@191134 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify the ProcessSingleton API.erikwright@chromium.org2013-03-281-11/+7
| | | | | | | | | | Instead of having multiple functions that take a callback to initialize a member variable, intitialize the member once during the constructor. This reduces the variability of the internal state of ProcessSingleton. BUG=170726, 170734 Review URL: https://chromiumcodereview.appspot.com/12668027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@191131 0039d316-1c4b-4281-b951-d872f2087c98
* Show infobar in a metro chrome when trying to show the App Launcher.tapted@chromium.org2013-03-051-42/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, the app launcher (and v2 Chrome Apps) can only run in Desktop mode. If Chrome is configured for Metro mode and the user, from Windows 8 in desktop mode, clicks the App Launcher shortcut, Chrome needs to switch to Desktop mode in order for it to work. This change prompts the user in Metro mode via an infobar on about:blank, allowing them to cleanup other tabs before relaunching in Desktop mode. A local_pref setting allows the relaunch to automatically show the App Launcher once Chrome has relaunched on the desktop. BUG=165383 TEST=Run Chrome in Metro mode and switch Windows to desktop mode. Click the App Launcher icon. Infobar should be shown offering to relaunch Chrome on the Desktop. This should work if Chrome is configured for Metro mode, whether or not it is currently running. Review URL: https://chromiumcodereview.appspot.com/12385013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@186113 0039d316-1c4b-4281-b951-d872f2087c98
* Move file_path.h to base/files.brettw@chromium.org2013-02-241-1/+1
| | | | | | TBR=sky git-svn-id: svn://svn.chromium.org/chrome/trunk/src@184344 0039d316-1c4b-4281-b951-d872f2087c98
* Merge branch 'master' into file_path_browserbrettw@chromium.org2013-02-101-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | version control markers Merge branch 'master' into file_path_browser remove version control Fix typo Merge branch 'master' into file_path_browser Conflicts: chrome/browser/intents/native_services_browsertest.cc chrome/browser/ui/intents/native_file_picker_service.cc Merge branch 'master' into file_path_browser Conflicts: chrome/browser/chromeos/drive/drive_file_system.cc chrome/browser/chromeos/drive/drive_file_system.h chrome/browser/chromeos/drive/drive_file_system_interface.h chrome/browser/chromeos/drive/drive_file_system_unittest.cc chrome/browser/chromeos/drive/file_system/drive_operations.cc chrome/browser/chromeos/login/wallpaper_manager.cc chrome/browser/chromeos/login/wallpaper_manager.h chrome/browser/chromeos/login/wallpaper_manager_browsertest.cc chrome/browser/extensions/api/sync_file_system/extension_sync_event_observer.cc chrome/browser/google_apis/gdata_wapi_operations.cc chrome/browser/google_apis/gdata_wapi_operations.h chrome/browser/google_apis/gdata_wapi_operations_unittest.cc chrome/browser/profiles/off_the_record_profile_impl.cc chrome/browser/profiles/off_the_record_profile_impl.h chrome/browser/profiles/profile_impl.cc chrome/browser/profiles/profile_impl.h chrome/browser/profiles/profile_impl_io_data.cc chrome/browser/profiles/profile_impl_io_data.h chrome/browser/sync_file_system/drive_file_sync_client_unittest.cc chrome/browser/ui/webui/options/manage_profile_handler.cc Long lines long lines some long lines. long lines long lines Beginning of lines. Rename FilePath -> base::FilePath in chrome/browser git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181638 0039d316-1c4b-4281-b951-d872f2087c98
* Add a UMA stat to track whether Chrome is the default browser.robertshield@chromium.org2012-12-111-1/+1
| | | | | | | | | | | | Also alter the default browser enum in ShellIntegration to be compatible with UMA, and shorten needlessly-long enum value names. BUG=164653 TEST=NONE Review URL: https://chromiumcodereview.appspot.com/11472007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@172346 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a recent regression which caused the Windows 8 Chrome Ash viewer process ↵ananta@chromium.org2012-12-071-2/+3
| | | | | | | | | | | | | to fail to connect to the chrome browser process. Fix is to invoke the PlatformSpecificCommandLineProcessing function in the BrowserProcess instance if we fail to find an existing browser process to defer to. BUG=151718 R=cpu Review URL: https://codereview.chromium.org/11464030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171866 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ProcessSingleton regression: if the notified process is immersive and is ↵gab@chromium.org2012-12-061-9/+10
| | | | | | | | | | | | | | | | | suspended, it must first be activated before it can process any window messages. This used to work before http://crrev.com/171105 because we would always Activate chrome (if such was the pref) and sleep in the ProcessSingleton's constructor before continuing, so that (if we hopefully slept long enough) we would fail to Create() and would successfully NotifyOtherProcess(). Now that we only Activate if necessary in Create(), Chrome can still be suspended when we get to NotifyOtherProcess(), in which case SendMessageTimeout() fails and we end up killing the process (thinking it's hung). To solve the problem, always Activate before notifying if the notified process is immersive. BUG=155585 TEST=Launch Chrome in Metro, wait until the process is suspended, launch chrome.exe from the command-line, make sure Chrome is activated (not killed!). Review URL: https://chromiumcodereview.appspot.com/11441022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171380 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor ProcessSingleton to allow a Desktop process to activate Metro ↵gab@chromium.org2012-12-051-107/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | Chrome instead of grabbing the singleton (while making sure it simply RDVs if there already is an existing Chrome). Use a Windows event to let the Metro process notify the Desktop process once it grabbed the singleton (no more Sleep()). The idea is the following: 0) Any process always tries to rendez-vous before anything else. 1) A Metro process can always try to grab the singleton. 2) A Desktop process might wait if: a) The metro activation event exists b) The metro activation event doesn't exist, but ShouldActivate() returns true - In which case it creates the metro activation event and activates Metro Chrome (which will notify this process via the event once it grabbed the singleton; at which point this process should rendez-vous with it). All of this is done while holding a global mutex (only releasing it while waiting and re-acquiring it before continuing when notified). The process singleton acquiring logic has also been moved from the constructor to Create(). BUG=155585, 159869 TEST=Process singleton works as before (and better in tricky corner cases -- see http://crbug.com/159869) on Win8. Review URL: https://chromiumcodereview.appspot.com/11099053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171105 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that Metro chrome in ASH is able to connect to an existing desktop ↵ananta@chromium.org2012-11-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | chrome AURA process. To achieve this the following changes were made. 1. Moved the MetroViewerProcessHost instance from the ChromeBrowserMainPartsWin class to the BrowserProcessImpl class. 2. We instantiate the MetroViewerProcessHost class as needed, i.e. when the command line for the current browser process specifies that a metro viewer is being created and when a chrome browser process delegates to an existing desktop chrome browser process passing in the metro viewer command line. 3. The functionality to process a commmand line is provided by the new virtual function PlatformSpecificCommandLineProcessing which is invoked during startup and when a newly launched chrome browser process delegates to an already running instance. I also added a call to CloseAsh in the channel error handling in the MetroViewerProcessHost class, to ensure that subsequent launches of Chrome Ash in metro succeed. BUG=151718 R=sky Review URL: https://codereview.chromium.org/11299192 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@169777 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 166582 - Force Metro vs Desktop preference back to Desktop when ↵gab@chromium.org2012-11-141-4/+4
| | | | | | | | | | | | | | | | Chrome is launched after it lost default browser. BUG=159869 TEST=Singleton-mode still works as expected. Launching Chrome after it lost default launches on Desktop, setting as default again and relaunching it still launches from Desktop even if pref used to be to launch in Metro. Prefer Metro mode, set IE as default, set Chrome back to default without launching it in between, Chrome still launches in Metro mode. Review URL: https://codereview.chromium.org/11369122 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/11410089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167683 0039d316-1c4b-4281-b951-d872f2087c98
* Force Metro vs Desktop preference back to Desktop when Chrome is launched ↵gab@chromium.org2012-11-081-4/+4
| | | | | | | | | | | | | after it lost default browser. BUG=159869 TEST=Singleton-mode still works as expected. Launching Chrome after it lost default launches on Desktop, setting as default again and relaunching it still launches from Desktop even if pref used to be to launch in Metro. Prefer Metro mode, set IE as default, set Chrome back to default without launching it in between, Chrome still launches in Metro mode. Review URL: https://codereview.chromium.org/11369122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166582 0039d316-1c4b-4281-b951-d872f2087c98
* Do not activate Metro Chrome when a chrome.exe is called with a short-lived ↵gab@chromium.org2012-10-131-10/+20
| | | | | | | | | | | command. BUG=155625 Review URL: https://chromiumcodereview.appspot.com/11141004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161723 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome should never attempt to launch in Metro if it is no longer default ↵gab@chromium.org2012-10-131-4/+8
| | | | | | | | | | | browser BUG=155079 Review URL: https://chromiumcodereview.appspot.com/11103008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161698 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a regression which caused Chrome to always launch in Windows 8 mode on ↵ananta@chromium.org2012-10-101-4/+8
| | | | | | | | | | | | | | | tablets. This was caused by my change to fix bug http://code.google.com/p/chromium/issues/detail?id=153318 which attempted to activate chrome in Windows 8 mode if the previous launch mode was Windows 8. We also don't attempt to activate into metro if the command line contains the uninstall switch. BUG=154663 R=sky Review URL: https://codereview.chromium.org/11066102 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161217 0039d316-1c4b-4281-b951-d872f2087c98
* Desktop Chrome on Windows 8 should attempt to relaunch into immersive mode ↵ananta@chromium.org2012-10-051-0/+67
| | | | | | | | | | | | | | | | | | | if the previous run was immersive or if the machine is a tablet. This is in line with the expectations of the Windows 8 Chrome Singleton approach where we have one of Chrome desktop/Chrome Windows 8 immersive mode running at any given time. Fixes bug http://code.google.com/p/chromium/issues/detail?id=153318 BUG=153318 R=sky Relaunch Chrome on Windows 8 into immersive mode if the previous run was Review URL: https://codereview.chromium.org/11026053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@160436 0039d316-1c4b-4281-b951-d872f2087c98
* Enable EULA dialog to be shown from metro Chrome.robertshield@chromium.org2012-09-261-1/+3
| | | | | | | | | | BUG=131033 TEST=Run Chrome in Metro mode while the EULA dialog still needs to be accepted. Get kicked back to the desktop to accept the dialog. On accept, get kicked back into metro mode. Review URL: https://chromiumcodereview.appspot.com/10837222 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158797 0039d316-1c4b-4281-b951-d872f2087c98
* If desktop chrome is launched via the New Window/the recently opened url ↵ananta@chromium.org2012-09-181-0/+48
| | | | | | | | | | | | | | shortcuts on the chrome shortcut or simply from the command line, if we defer to immersive chrome if it is already running, then we should also activate the metro chrome instance. Added a helper function IsProcessImmersive which takes in the process handle to determine if it is immersive to base\win\metro.cc/.h BUG=144297 R=cpu Review URL: https://codereview.chromium.org/10910311 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157250 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the tree.cpu@chromium.org2012-08-221-0/+2
| | | | | | | | | | Forgot windows include BUG=none TBR=scottmg Review URL: https://chromiumcodereview.appspot.com/10872021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@152840 0039d316-1c4b-4281-b951-d872f2087c98
* Implement forwarding of search queries for metro modecpu@chromium.org2012-08-221-9/+38
| | | | | | | | | | | | | | | | | | | If chrome is the default browser, launch from the search charm does not use the delegate_execute so if desktop chrome is running, metro chrome needs to forward the search string and quickly quite The source of complexity here is that to form the full url, chrome needs to access the profile which cannot be done from the metro chrome since the desktop chrome has the profile locked. Instead we leveage the kMetroNavigationAndSearchMessage from the singleton code. BUG=141032 TEST= see bug Review URL: https://chromiumcodereview.appspot.com/10824387 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@152818 0039d316-1c4b-4281-b951-d872f2087c98
* Implement lock file for windows profiles.pastarmovj@chromium.org2012-07-171-17/+41
| | | | | | | | | | BUG=120389 TEST=Start chrome from two PCs at the same time with shared profile and observe the second instance not starting at all. Review URL: https://chromiumcodereview.appspot.com/10702159 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@147121 0039d316-1c4b-4281-b951-d872f2087c98
* browser: Put simple_message_box.h and chrome_web_contents_view_delegate.h ↵tfarina@chromium.org2012-07-041-2/+2
| | | | | | | | | | | into chrome namespace. BUG=133088 TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/10689095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@145421 0039d316-1c4b-4281-b951-d872f2087c98
* Move the window destruction and registration out of cleanup and into ↵rlp@chromium.org2012-06-181-13/+8
| | | | | | | | | | | BrowserProcessImpl::EndSession to make sure it happens after profiles are written out. BUG=127607 TEST=Run on slow computer, open three or more profiles, exit from wrench menu, immediately open chrome again. There should be no reports of profile corruption and logs should show that profile writing is not occuring after second chrome starts. Review URL: https://chromiumcodereview.appspot.com/10542151 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142682 0039d316-1c4b-4281-b951-d872f2087c98
* browser: Fold ShowQuestionMessageBox() into ShowMessageBox() function.tfarina@chromium.org2012-05-261-8/+6
| | | | | | | | | R=pkasting@chromium.org,erg@chromium.org,rsesek@chromium.org TBR=sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/10412016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@139205 0039d316-1c4b-4281-b951-d872f2087c98
* Move chrome/browser/simple_message_box.h to chrome/browser/ui.thestig@chromium.org2012-05-131-1/+1
| | | | | | | | BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/10384116 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@136798 0039d316-1c4b-4281-b951-d872f2087c98
* browser: Rename two message box functions to more accurate names.tfarina@chromium.org2012-04-231-3/+4
| | | | | | | | | | | This is a follow up to r132847. R=msw@chromium.org TBR=sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/10164019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133396 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor ProcessSingleton so that it may be used distinctly from a full ↵erikwright@chromium.org2012-04-051-54/+13
| | | | | | | | | | | | | | | | | browser process. The main effect is that ProcessSingleton is much more restricted to its basic functionality, which is to ensure that a single instance of Chrome runs per profile directory and to pass messages from new Chrome invocations to the existing instance. Exactly how those messages were handled has been moved from the implementations of ProcessSingleton into ChromeBrowserMain where (I think) it more rightly belongs. This will allow the Chrome Frame net tests to use ProcessSingleton to implement a stub Chrome for the purpose of handling network-related IPC from Chrome Frame without having to launch the rest of Chrome, upon which ProcessSingleton previously depended directly. BUG=None TEST=None Review URL: http://codereview.chromium.org/9968053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130853 0039d316-1c4b-4281-b951-d872f2087c98
* Fix attempt for the double-SessionRestoreImpl problem.marja@chromium.org2012-02-231-82/+106
| | | | | | | | | | | | | | The problem is that BrowserInit::ProcessCommandLineAlreadyRunning gets called too early, before launching the first profile during normal startup. BUG=111238 TEST=NONE Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=122065 Review URL: https://chromiumcodereview.appspot.com/9365049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123209 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 122079 - Revert 122077 - Revert 122065 - Fix attempt for the ↵marja@chromium.org2012-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | double-SessionRestoreImpl problem. The problem is that BrowserInit::ProcessCommandLineAlreadyRunning gets called too early, before launching the first profile during normal startup. BUG=111238 TEST=NONE Review URL: http://codereview.chromium.org/9365049 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9402007 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9409001 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9403015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122088 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 122077 - Revert 122065 - Fix attempt for the ↵marja@chromium.org2012-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | double-SessionRestoreImpl problem. The problem is that BrowserInit::ProcessCommandLineAlreadyRunning gets called too early, before launching the first profile during normal startup. BUG=111238 TEST=NONE Review URL: http://codereview.chromium.org/9365049 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9402007 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9409001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122079 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 122065 - Fix attempt for the double-SessionRestoreImpl problem.marja@chromium.org2012-02-151-1/+1
| | | | | | | | | | | | | | | | The problem is that BrowserInit::ProcessCommandLineAlreadyRunning gets called too early, before launching the first profile during normal startup. BUG=111238 TEST=NONE Review URL: http://codereview.chromium.org/9365049 TBR=marja@chromium.org Review URL: https://chromiumcodereview.appspot.com/9402007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122077 0039d316-1c4b-4281-b951-d872f2087c98
* Fix attempt for the double-SessionRestoreImpl problem.marja@chromium.org2012-02-151-1/+1
| | | | | | | | | | | | | The problem is that BrowserInit::ProcessCommandLineAlreadyRunning gets called too early, before launching the first profile during normal startup. BUG=111238 TEST=NONE Review URL: http://codereview.chromium.org/9365049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122065 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup in ProcessSingleton. These originated as candidate fixes for issue ↵joi@chromium.org2012-02-101-38/+42
| | | | | | | | | | | | | | | | | 111361, but the true fix is cpu@'s r119830. a) Unify code to retrieve HMODULE based on address in base::GetModuleFromAddress. (cpu@'s r119830 already has the fix to use the DLL's HMODULE 119830 rather than the EXE's HINSTANCE) b) Try harder to unregister the window class, by trying it first in ProcessSingleton::Cleanup, which gets called before the fast shutdown path calls ExitProcess(). Also, use correct HMODULE to unregister. c) Avoid any possibility of a race to create the message window when the Create() method is called from NotifyOtherProcessOrCreate() or from outside the class by moving the implementation of Create(), which was always called from the constructor, into the constructor and making Create() just return true or false based on the success of the work already done. BUG=111361 Review URL: http://codereview.chromium.org/9121046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@121480 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bogus thunking of the 'Chrome_MessageWindow'cpu@chromium.org2012-01-311-14/+35
| | | | | | | | | | | | | | | | ProcessSingleton::WndProc was being invoked with |this| == NULL and somehow base::win::WrappedWindowProc<> eats the exceptions causing the critical return from WM_CREATE to not be zero and thus window creation fails. Other Minor fixes, inspiration from Joi's change 9121046 BUG=111361 TEST=crashes should dissapear, see bug. Review URL: http://codereview.chromium.org/9298043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@119830 0039d316-1c4b-4281-b951-d872f2087c98
* Honor profile directory when creating new window in existing browsersail@chromium.org2011-12-081-10/+13
| | | | | | | | | | | | | | Using the "-profile-directory" switch didn't work if the browser was already running. The problem was that we were ignoring the switch and just using the last used profile. BUG=100461 TEST=Ran Chrome with the first profile open. Launched a 2nd instance with "-profile-directory" and verified that the correct profile window opened. Review URL: http://codereview.chromium.org/8854001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@113534 0039d316-1c4b-4281-b951-d872f2087c98
* aura: Use native ProcessSingleton implementations.derat@chromium.org2011-10-251-0/+4
| | | | | | | | | | | | | | | | | | | This makes us use either ProcessSingletonLinux or ProcessSingletonWin. Tested on a Chrome OS device by starting two separate Chrome processes with the same profile directory. The second process just opened another window in the original Aura desktop instead of crashing after trying to open a locked database as before. sky@ was kind enough to run this for me on Windows and confirm that it behaves similarly there. BUG=99713 TEST=manual: see above Review URL: http://codereview.chromium.org/8382023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107236 0039d316-1c4b-4281-b951-d872f2087c98
* Move resource_codes to content/public/common.jam@chromium.org2011-10-251-1/+1
| | | | | | | BUG=98716 Review URL: http://codereview.chromium.org/8382021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107061 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that process_singleton will do the right thing if the default profile ↵mirandac@chromium.org2011-10-201-1/+1
| | | | | | | | | | | has been deleted. BUG=100951 TEST=see bug report for details of linux test. Review URL: http://codereview.chromium.org/8345016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@106617 0039d316-1c4b-4281-b951-d872f2087c98
* If Softricity DLLs are detected relaunch Chrome via WMIjschuh@chromium.org2011-09-141-3/+38
| | | | | | | | BUG=43650 TEST=Click on a youtube.com link in Outlook or Word Starter Edition Review URL: http://codereview.chromium.org/7889015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@101105 0039d316-1c4b-4281-b951-d872f2087c98
* browser: Abstract message box dialog functions into its own header file.tfarina@chromium.org2011-08-091-6/+4
| | | | | | | | | | | BUG=None TEST=None R=evan@chromium.org Review URL: http://codereview.chromium.org/7601014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@96071 0039d316-1c4b-4281-b951-d872f2087c98
* Take two at splitting result codes between content and chrome.dpranke@chromium.org2011-07-191-1/+1
| | | | | | | | | | | | content/common/result_codes.h contains only the codes defined in content. chrome/common/chrome_result_codes.h contains the codes defined in chrome and also includes (for convenience) the content header. R=jam@chromium.org BUG=76699 TEST=everything compiles Review URL: http://codereview.chromium.org/7397004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@93082 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-05-20 16:12:28 +0000