Pre-cache downloads directory path in PathUtils.

Pre-cache downloads directory path in PathUtils.

When Chrome tabs are swiped away and user starts Chrome again,
their default downloads directory is requested. This causes a
StrictMode policy violation since it results in a ~60ms disk
read. Thus by adding this call to the initial AsyncTask we
save that time when the directory is requested by native.

This must only be called in the browser process as the sandbox
processes do not need to make the call nor can they make the
call(results in NPE).

BUG=508615
Committed: https://crrev.com/4a7568dffab924d3710a68949dca0717bdad3352
Cr-Commit-Position: refs/heads/master@{#342672}

[Peter Wen, 2015-08-10 17:32:40]

wnwen@chromium.org changed reviewers:
+ yfriedman@google.com

[Peter Wen, 2015-08-10 17:32:40]

Hi Yaron,

I have verified that adding this is okay and does not extend the length of the
AsyncTask beyond what can be completed almost instantly on initial load.

Thanks,

Peter

[Yaron, 2015-08-10 17:37:38]

On 2015/08/10 17:32:40, Peter Wen wrote:
> Hi Yaron,
> 
> I have verified that adding this is okay and does not extend the length of the
> AsyncTask beyond what can be completed almost instantly on initial load.
> 
> Thanks,
> 
> Peter

And you've verified that it's not normally needed on startup? i.e. that we
aren't just shifting the strict mode to the .get on the asynctask?

[Peter Wen, 2015-08-10 17:41:05]

On 2015/08/10 17:37:38, Yaron wrote:
> On 2015/08/10 17:32:40, Peter Wen wrote:
> > Hi Yaron,
> > 
> > I have verified that adding this is okay and does not extend the length of
the
> > AsyncTask beyond what can be completed almost instantly on initial load.
> > 
> > Thanks,
> > 
> > Peter
> 
> And you've verified that it's not normally needed on startup? i.e. that we
> aren't just shifting the strict mode to the .get on the asynctask?

Yep, this is called by native and the AsyncTask is started before the library is
completely loaded.

[Peter Wen, 2015-08-10 17:42:43]

On 2015/08/10 17:41:05, Peter Wen wrote:
> On 2015/08/10 17:37:38, Yaron wrote:
> > On 2015/08/10 17:32:40, Peter Wen wrote:
> > > Hi Yaron,
> > > 
> > > I have verified that adding this is okay and does not extend the length of
> the
> > > AsyncTask beyond what can be completed almost instantly on initial load.
> > > 
> > > Thanks,
> > > 
> > > Peter
> > 
> > And you've verified that it's not normally needed on startup? i.e. that we
> > aren't just shifting the strict mode to the .get on the asynctask?
> 
> Yep, this is called by native and the AsyncTask is started before the library
is
> completely loaded.

Also, at least on the N5, the async task always completes long before any .get
is called.

[Yaron, 2015-08-10 18:07:10]

On 2015/08/10 17:42:43, Peter Wen wrote:
> On 2015/08/10 17:41:05, Peter Wen wrote:
> > On 2015/08/10 17:37:38, Yaron wrote:
> > > On 2015/08/10 17:32:40, Peter Wen wrote:
> > > > Hi Yaron,
> > > > 
> > > > I have verified that adding this is okay and does not extend the length
of
> > the
> > > > AsyncTask beyond what can be completed almost instantly on initial load.
> > > > 
> > > > Thanks,
> > > > 
> > > > Peter
> > > 
> > > And you've verified that it's not normally needed on startup? i.e. that we
> > > aren't just shifting the strict mode to the .get on the asynctask?
> > 
> > Yep, this is called by native and the AsyncTask is started before the
library
> is
> > completely loaded.
> 
> Also, at least on the N5, the async task always completes long before any .get
> is called.

lgtm

I guess this is fine for now the same way as the others are, but I'm curious
about a better fix which would ensure we delay work until the path is available

[Peter Wen, 2015-08-10 18:16:35]

On 2015/08/10 18:07:10, Yaron wrote:
> On 2015/08/10 17:42:43, Peter Wen wrote:
> > On 2015/08/10 17:41:05, Peter Wen wrote:
> > > On 2015/08/10 17:37:38, Yaron wrote:
> > > > On 2015/08/10 17:32:40, Peter Wen wrote:
> > > > > Hi Yaron,
> > > > > 
> > > > > I have verified that adding this is okay and does not extend the
length
> of
> > > the
> > > > > AsyncTask beyond what can be completed almost instantly on initial
load.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Peter
> > > > 
> > > > And you've verified that it's not normally needed on startup? i.e. that
we
> > > > aren't just shifting the strict mode to the .get on the asynctask?
> > > 
> > > Yep, this is called by native and the AsyncTask is started before the
> library
> > is
> > > completely loaded.
> > 
> > Also, at least on the N5, the async task always completes long before any
.get
> > is called.
> 
> lgtm
> 
> I guess this is fine for now the same way as the others are, but I'm curious
> about a better fix which would ensure we delay work until the path is
available

Hmm... I think the best fix would be to redesign the directory/file path request
paradigm in Chrome. Currently on all platforms it is assumed to be a synchronous
operation, which then results in us having to make these concessions to hide
that
latency. Something like the callback structure that most javascript programs
exhibit.

Not sure what a good intermediate step/improvement would be, will keep this in
mind. :)

[Peter Wen, 2015-08-10 18:16:38]

The CQ bit was checked by wnwen@chromium.org

[commit-bot: I haz the power, 2015-08-10 18:16:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1281273003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1281273003/1

[commit-bot: I haz the power, 2015-08-10 19:30:07]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-08-10 19:30:44]

Patchset 1 (id:??) landed as
https://crrev.com/4a7568dffab924d3710a68949dca0717bdad3352
Cr-Commit-Position: refs/heads/master@{#342672}

[mimee1, 2015-09-04 22:29:36]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1328043002/ by mimee@google.com.

The reason for reverting is: Revert because it breaks new beta. See
https://code.google.com/p/chromium/issues/detail?id=528377
.