Remove DownloadItem::GetUserVerifiedFilePath()

Remove DownloadItem::GetUserVerifiedFilePath()

This method returned the intermediate path
(i.e. "Unconfirmed_nnn.crdownload") for a dangerous download and the
target path for a safe download. It was being used for:

- Associating the 'Always open files of this type' preference. Updated
  to use GetTargetFilePath() instead as using the intermediate path
  for this purpose is incorrect.

- Fetching the icon for a download. Updated to use GetTargetFilePath()
  for this as well. On Windows some file types should be queried again
  for the icon after the download completes. This is handled by
  download_item_view.cc.

BUG=134237
BUG=137702
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=201599

[asanka, 2013-05-08 21:39:54]

Ben: Can you take a look?

[benjhayden, 2013-05-09 15:00:01]

LGTM
Yay quick bugfixes!

Those bugs say that we want to use GetFullPath for Show in Folder.
 * When would GetFullPath().DirName() != GetTargetFilePath().DirName()?
 * Wouldn't it be confusing for Show in Folder to open a directory that contains
a temporary file, then the temporary file is moved to the target directory so
that the shell window opened by Show in Folder no longer contains the downloaded
file? Should the UI wait to display the Show in Folder link until the file is in
the target directory?

Can you update 137702 to list the remaining accessors that need to be nuked?

[asanka, 2013-05-09 18:55:53]

On 2013/05/09 15:00:01, benjhayden_chromium wrote:
> LGTM
> Yay quick bugfixes!

Thanks!

> Those bugs say that we want to use GetFullPath for Show in Folder.
>  * When would GetFullPath().DirName() != GetTargetFilePath().DirName()?

During the gap between filename determination completes and the initial rename
completes, GetFullPath() would be empty and GetTargetFilePath() be non-empty.

Also, an interrupted download may have GetFullPath() be empty.

Other than that, we always keep the intermediate file in the same directory as
the target file.

>  * Wouldn't it be confusing for Show in Folder to open a directory that
contains
> a temporary file, then the temporary file is moved to the target directory so
> that the shell window opened by Show in Folder no longer contains the
downloaded
> file? Should the UI wait to display the Show in Folder link until the file is
in
> the target directory?

Addressed above.

> Can you update 137702 to list the remaining accessors that need to be nuked?

Yup. Once this lands, I'll update the issue.

[commit-bot: I haz the power, 2013-05-09 18:56:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/asanka@chromium.org/15011006/1

[asanka, 2013-05-09 19:26:42]

Adding OWNERS:

phajdan.jr:
  chrome/browser/automation/

thakis:
  chrome/browser/ui/cocoa/download/

estade:
  chrome/browser/ui/gtk/download/

sky:
  chrome/browser/ui/views/download/

joi:
  content/public/

[Jói, 2013-05-09 20:26:59]

LGTM for content/public.

[sky, 2013-05-09 21:20:03]

LGTM

[Paweł Hajdan Jr., 2013-05-09 21:24:54]

automation LGTM

[Nico, 2013-05-09 21:31:26]

cocoa lgtm stamp

[Evan Stade, 2013-05-13 20:53:11]

gtk lgtm

[commit-bot: I haz the power, 2013-05-21 20:01:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/asanka@chromium.org/15011006/16001

[commit-bot: I haz the power, 2013-05-22 00:24:32]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-05-22 15:55:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/asanka@chromium.org/15011006/16001

[commit-bot: I haz the power, 2013-05-22 19:17:07]

Change committed as 201599