Call RecordLastRunAppBundlePath in FILE thread

Call RecordLastRunAppBundlePath in FILE thread

RecordLastRunAppBundlePath() uses chrome::GetVersionedDirectory()
which in turn uses PathProvider for base::DIR_EXE, which will do I/O
on OS X since it uses base::MakeAbsoluteFilePath() now.

Reorder the sync call a bit so that we don't have to post another
FILE thread task to get the preferences synced.

BUG=275988
TEST=Run Chromium; do (from command line):
"defaults read org.chromium.Chromium LastRunAppBundlePath"
-- should get path to Chromium.app; move Chromium.app to another
location and run it again; do "defaults ..." again -- should get path
to Chromium.app at new location.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=220168

[Nico, 2013-08-22 14:00:10]

Thanks for working on this!

One effect of this change is that kLastRunAppBundlePathPrefsKey is now populated
1.5s later. I think this is used for apps, so +sail, benwells to check if they
see issues with this. Possibly better to set kLastRunAppBundlePathPrefsKey
immediately and only do the prefs sync after 1.5s, not sure. If sail or benwells
are happy with this change, lgtm as is.

[tapted, 2013-08-22 23:28:04]

https://codereview.chromium.org/22966010/diff/1/chrome/browser/app_controller...
File chrome/browser/app_controller_mac.mm (right):

https://codereview.chromium.org/22966010/diff/1/chrome/browser/app_controller...
chrome/browser/app_controller_mac.mm:171:
chrome::GetVersionedDirectory().DirName().DirName().DirName();
drive-by: Is there an issue down the code path

GetVersionedDirectory()
 -> IsBackgroundOnlyProcess()
  ->  [NSBundle infoDictionary]

NSBundle isn't threadsafe according to most sources. But this is just reading
from the plist. If it's a problem, the return value from
base::mac::IsBackgroundOnlyProcess() could be fed through from the UI thread.

[Jiang Jiang, 2013-08-23 08:00:19]

On 2013/08/22 14:00:10, Nico (vacation Aug 2 - Aug 22) wrote:
> Thanks for working on this!
> 
> One effect of this change is that kLastRunAppBundlePathPrefsKey is now
populated
> 1.5s later. I think this is used for apps, so +sail, benwells to check if they
> see issues with this. Possibly better to set kLastRunAppBundlePathPrefsKey
> immediately and only do the prefs sync after 1.5s, not sure. If sail or
benwells
> are happy with this change, lgtm as is.

After thinking about it more thorough, I think being able to set the preferences
immediately after -applicationDidFinishLaunching: can be better since if you
quit between this and the 1500ms delay, the app might still force pref sync. If
we just postpone the entire operation then nothing will be saved.

[commit-bot: I haz the power, 2013-08-28 20:14:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jiangj@opera.com/22966010/8001

[commit-bot: I haz the power, 2013-08-29 03:09:17]

Change committed as 220168