Download filename determination refactor (3/3)

Download filename determination refactor (3/3)

Move prompting logic from content/ to chrome/. When determining
the target path for a download, we used to notify content/ of
what the target path was along with a flag indicating whether the
user should be prompted. Then DownloadManager would call into the
DownloadManagerDelegate to request a prompt if necessary. This
patch short circuits the logic so that the
DownloadManagerDelegate would prompt the user as necessary and
only pass the final path to the DownloadItem.

BUG=78085
TEST=unit tests
TBR=sky,mirandac

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=148703

[asanka, 2012-07-03 21:33:19]

Can you take a high level look at where this is going? It doesn't have updated
tests yet, but it's changing enough of the API that I would like to hear
objections early :)

[Randy Smith (Not in Mondays), 2012-07-05 15:42:32]

This was a very high level review (which means in this case that I looked
carefully at download_manager_delegate.h and download_manager{_impl}.h and
lightly at the rest of the .h files).  Given that I'd like changes at that
level, I figured I'd toss the results back at you and see what you thought :-}.

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:297:
download_manager->ClearTransientState();
Given that this is in chrome, could it get the CDMD and call the function on
that directly, thus avoiding the need for the indirects through the DM?

http://codereview.chromium.org/10704052/diff/1022/content/browser/download/do...
File content/browser/download/download_manager_impl.h (left):

http://codereview.chromium.org/10704052/diff/1022/content/browser/download/do...
content/browser/download/download_manager_impl.h:160: void
OnTargetPathAvailable(content::DownloadItem* download);
As noted in dmd.h this interface implies the DMD is changing state directly on
the DI.  I'd rather do that in the download system; any chance this API could be
expanded to pass the information back through it?

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:45: // Notifies the delegate
that a new download needs
nit: dangling sentence.

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:50: // return |true| if it
has or will invoke OnDownloadTargetDetermined(). If it
The interface on DMI is OnDownloadTargetAvailable, which I think is an
inconsistency?

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:50: // return |true| if it
has or will invoke OnDownloadTargetDetermined(). If it
Could we do this through a callback rather than a specified interface on the DM?

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:52: // default, possibly
empty, target path.
When I look at the new DMI interface (OnDownloadTargetAvailable) it looks to me
like this is expecting the DMD to change state directly on the DownloadItem.  My
preference would be to keep state changes inside of the core download system,
which would mean making the callback take the passed back information and doing
the state transition then.   How hard would it be to do it this way?

(Eventually, I'd like the call out to come from the DI, indirect through the DM,
and hit the DMD, with a callback passed to get the results, which means we won't
have to have any setters for this process on the DI.  Not for this CL :-}.)

[asanka, 2012-07-09 21:13:46]

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:297:
download_manager->ClearTransientState();
On 2012/07/05 15:42:32, rdsmith wrote:
> Given that this is in chrome, could it get the CDMD and call the function on
> that directly, thus avoiding the need for the indirects through the DM?

Hmm. That makes sense. I didn't see a very clean way to get at the CDMD from
here. Perhaps add a method to DownloadService to return the
ChromeDownloadManagerDelegate for the profile?

http://codereview.chromium.org/10704052/diff/1022/content/browser/download/do...
File content/browser/download/download_manager_impl.h (left):

http://codereview.chromium.org/10704052/diff/1022/content/browser/download/do...
content/browser/download/download_manager_impl.h:160: void
OnTargetPathAvailable(content::DownloadItem* download);
On 2012/07/05 15:42:32, rdsmith wrote:
> As noted in dmd.h this interface implies the DMD is changing state directly on
> the DI.  I'd rather do that in the download system; any chance this API could
be
> expanded to pass the information back through it?

Done.

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:45: // Notifies the delegate
that a new download needs
On 2012/07/05 15:42:32, rdsmith wrote:
> nit: dangling sentence.

Done.

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:50: // return |true| if it
has or will invoke OnDownloadTargetDetermined(). If it
On 2012/07/05 15:42:32, rdsmith wrote:
> The interface on DMI is OnDownloadTargetAvailable, which I think is an
> inconsistency?

Done.

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:50: // return |true| if it
has or will invoke OnDownloadTargetDetermined(). If it
On 2012/07/05 15:42:32, rdsmith wrote:
> Could we do this through a callback rather than a specified interface on the
DM?

Done.

http://codereview.chromium.org/10704052/diff/1022/content/public/browser/down...
content/public/browser/download_manager_delegate.h:52: // default, possibly
empty, target path.
On 2012/07/05 15:42:32, rdsmith wrote:
> When I look at the new DMI interface (OnDownloadTargetAvailable) it looks to
me
> like this is expecting the DMD to change state directly on the DownloadItem. 
My
> preference would be to keep state changes inside of the core download system,
> which would mean making the callback take the passed back information and
doing
> the state transition then.   How hard would it be to do it this way?
> 
> (Eventually, I'd like the call out to come from the DI, indirect through the
DM,
> and hit the DMD, with a callback passed to get the results, which means we
won't
> have to have any setters for this process on the DI.  Not for this CL :-}.)  

I added a callback parameter that the DMD is supposed to invoke if it wants to
determine an explicit path.

[Randy Smith (Not in Mondays), 2012-07-10 18:33:09]

Basic approach looks good to me, modulo the ClearTransientState() plumbing.  Let
me know when you'd like me to take a more thorough look.

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:297:
download_manager->ClearTransientState();
On 2012/07/09 21:13:46, asanka wrote:
> On 2012/07/05 15:42:32, rdsmith wrote:
> > Given that this is in chrome, could it get the CDMD and call the function on
> > that directly, thus avoiding the need for the indirects through the DM?
> 
> Hmm. That makes sense. I didn't see a very clean way to get at the CDMD from
> here. Perhaps add a method to DownloadService to return the
> ChromeDownloadManagerDelegate for the profile?

I think it's already present, isn't it? 
(DownloadService::GetDownloadManagerDelegate())

http://codereview.chromium.org/10704052/diff/13001/chrome/browser/download/ch...
File chrome/browser/download/chrome_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/13001/chrome/browser/download/ch...
chrome/browser/download/chrome_download_manager_delegate.cc:147: // thread.
This comment seems very strange; can you clean it up appropriately while you're
here?

http://codereview.chromium.org/10704052/diff/13001/content/browser/download/d...
File content/browser/download/download_manager_impl.cc (right):

http://codereview.chromium.org/10704052/diff/13001/content/browser/download/d...
content/browser/download/download_manager_impl.cc:441: // download to proceed.
nit: Wouldn't the best place for this comment be above the direct call to
DI::OnDownloadTargetDetermined() below?

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
File content/public/browser/download_manager.h (left):

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager.h:95: DownloadManager* manager, int32
id) {}
The DownloadTestObserver overrides this still.  Not sure why that didn't provoke
a compile error.

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:54: // call
DownloadItem::OnDownloadTargetDetermined(). This function should
nit: "... required to call the callback."

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:57: // empty, target path.
nit: If you're allowing the callback to be invoked from inside this call (which
I *think* is not a common pattern in the code base) it's probably with being a
bit more explicit about it.  Just saying that the callback may be called
directly from the routine is fine.

http://codereview.chromium.org/10704052/diff/13001/content/shell/shell_downlo...
File content/shell/shell_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/13001/content/shell/shell_downlo...
content/shell/shell_download_manager_delegate.cc:93:
ChooseDownloadPath(download, suggested_path);
Any reason not to hoist the code in ChooseDownloadPath() up here?  We don't
really do anything else in this function, it's not called from anywhere else,
and it'd remove a function.  (Suggestion, not request.)

[Randy Smith (Not in Mondays), 2012-07-10 18:33:54]

Oh, just for reference, I'm probably not a good reviewer for the chromeos file
picker.

[asanka, 2012-07-11 20:03:32]

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:297:
download_manager->ClearTransientState();
On 2012/07/10 18:33:09, rdsmith wrote:
> On 2012/07/09 21:13:46, asanka wrote:
> > On 2012/07/05 15:42:32, rdsmith wrote:
> > > Given that this is in chrome, could it get the CDMD and call the function
on
> > > that directly, thus avoiding the need for the indirects through the DM?
> > 
> > Hmm. That makes sense. I didn't see a very clean way to get at the CDMD from
> > here. Perhaps add a method to DownloadService to return the
> > ChromeDownloadManagerDelegate for the profile?
> 
> I think it's already present, isn't it? 
> (DownloadService::GetDownloadManagerDelegate())

Hmm. I'd like to avoid up-casting if possible, but I think that should be okay.

http://codereview.chromium.org/10704052/diff/13001/chrome/browser/download/ch...
File chrome/browser/download/chrome_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/13001/chrome/browser/download/ch...
chrome/browser/download/chrome_download_manager_delegate.cc:147: // thread.
On 2012/07/10 18:33:09, rdsmith wrote:
> This comment seems very strange; can you clean it up appropriately while
you're
> here?

Removed.

http://codereview.chromium.org/10704052/diff/13001/content/browser/download/d...
File content/browser/download/download_manager_impl.cc (right):

http://codereview.chromium.org/10704052/diff/13001/content/browser/download/d...
content/browser/download/download_manager_impl.cc:441: // download to proceed.
On 2012/07/10 18:33:09, rdsmith wrote:
> nit: Wouldn't the best place for this comment be above the direct call to
> DI::OnDownloadTargetDetermined() below?

Done.

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
File content/public/browser/download_manager.h (left):

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager.h:95: DownloadManager* manager, int32
id) {}
On 2012/07/10 18:33:09, rdsmith wrote:
> The DownloadTestObserver overrides this still.  Not sure why that didn't
provoke
> a compile error.

Yeah. I haven't reworked the tests yet.

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:54: // call
DownloadItem::OnDownloadTargetDetermined(). This function should
On 2012/07/10 18:33:09, rdsmith wrote:
> nit: "... required to call the callback."

Done.

http://codereview.chromium.org/10704052/diff/13001/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:57: // empty, target path.
On 2012/07/10 18:33:09, rdsmith wrote:
> nit: If you're allowing the callback to be invoked from inside this call
(which
> I *think* is not a common pattern in the code base) it's probably with being a
> bit more explicit about it.  Just saying that the callback may be called
> directly from the routine is fine.

Done.

http://codereview.chromium.org/10704052/diff/13001/content/shell/shell_downlo...
File content/shell/shell_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/13001/content/shell/shell_downlo...
content/shell/shell_download_manager_delegate.cc:93:
ChooseDownloadPath(download, suggested_path);
On 2012/07/10 18:33:09, rdsmith wrote:
> Any reason not to hoist the code in ChooseDownloadPath() up here?  We don't
> really do anything else in this function, it's not called from anywhere else,
> and it'd remove a function.  (Suggestion, not request.)

I left it out since we might need to override it for testing.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:302:
download_service->GetDownloadManagerDelegate());
Changing DownloadService::GetDownloadManagerDelegate() to return a CDMD means
that profile_impl and off_the_record_profile_impl (and a couple of other places)
would need to know about CDMD.

[Randy Smith (Not in Mondays), 2012-07-12 16:35:37]

[Added John to cc list for question.  ]

On 2012/07/11 20:03:32, asanka wrote:
http://codereview.chromium.org/10704052/diff/1022/chrome/browser/browsing_dat...
> chrome/browser/browsing_data_remover.cc:297:
> download_manager->ClearTransientState();
> On 2012/07/10 18:33:09, rdsmith wrote:
> > On 2012/07/09 21:13:46, asanka wrote:
> > > On 2012/07/05 15:42:32, rdsmith wrote:
> > > > Given that this is in chrome, could it get the CDMD and call the
function
> on
> > > > that directly, thus avoiding the need for the indirects through the DM?
> > > 
> > > Hmm. That makes sense. I didn't see a very clean way to get at the CDMD
from
> > > here. Perhaps add a method to DownloadService to return the
> > > ChromeDownloadManagerDelegate for the profile?
> > 
> > I think it's already present, isn't it? 
> > (DownloadService::GetDownloadManagerDelegate())
> 
> Hmm. I'd like to avoid up-casting if possible, but I think that should be
okay.

Ah, right, hadn't noticed it returned a DMD rather than a CDMD.  I think it
would be fine to modify that method to return a CDMD; there's no content base
class for DownloadService that needs to get a DMD from that method, and
DownloadService itself is a chrome level concept.  I think that would actually
be reasonably clean architecturally.  On a practical level, the only place it's
called from is ProfileImpl and OffTheRecordProfileImpl, which will then
implicitly downcase the results to DMDs, so I think that would be fine.

John, do you see any problems to doing this?

[Randy Smith (Not in Mondays), 2012-07-12 17:01:22]

This looks pretty good.  

One more general question: I would have thought that we'd have problems with
DownloadTestObserver in removing SelectFileDialogDisplayed from
DownloadManagerObserver.  Did you not get a compile error because the OVERRIDE
isn't any more?  Or is there something about the relationship between
DownloadTestObserver and DMO that I'm not understanding.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:302:
download_service->GetDownloadManagerDelegate());
On 2012/07/11 20:03:32, asanka wrote:
> Changing DownloadService::GetDownloadManagerDelegate() to return a CDMD means
> that profile_impl and off_the_record_profile_impl (and a couple of other
places)
> would need to know about CDMD.

[Sorry, didn't see this in responding to your first comment.  ]

I think that's better than a static cast?

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
File chrome/browser/download/chrome_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
chrome/browser/download/chrome_download_manager_delegate.cc:718: //
TODO(asanka): Merge this logic with the logic in DownloadFilePickerChromeOS.
Probably worth pulling Achuith into the review at some point, to keep him
updated and in case he feels like taking this one.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
chrome/browser/download/chrome_download_manager_delegate.cc:793: //             
 persistable path after the DownloadFilePicker is done.
This is only for GData, right?  It should go away after we do the
DownloadDetermination refactor.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/dow...
File chrome/browser/download/download_file_picker.h (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/dow...
chrome/browser/download/download_file_picker.h:37: // On ChromeOS,
DownloadItem::GetTargetPath is a temporary local filename.
I don't see the relationship of this comment to the following routine--is it
stale?

http://codereview.chromium.org/10704052/diff/7005/content/public/browser/down...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/7005/content/public/browser/down...
content/public/browser/download_manager_delegate.h:57: // possibly empty, target
path.
I'd like to say something about the state changes that are possible on the
DownloadItem when calling this function.  I'd *like* the answer to be "none"
(i.e. only used for external data/observers), but that doesn't allow the user to
cancel if prompted.  So I'll settle for documenting what can and can't happen. 
(Though if it appealed to you to update DownloadTargetCallback to allow
propagating a cancel that way instead, I wouldn't object :-}.)

[asanka, 2012-07-18 21:50:55]

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
File chrome/browser/browsing_data_remover.cc (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/browsing_dat...
chrome/browser/browsing_data_remover.cc:302:
download_service->GetDownloadManagerDelegate());
On 2012/07/12 17:01:22, rdsmith wrote:
> On 2012/07/11 20:03:32, asanka wrote:
> > Changing DownloadService::GetDownloadManagerDelegate() to return a CDMD
means
> > that profile_impl and off_the_record_profile_impl (and a couple of other
> places)
> > would need to know about CDMD.
> 
> [Sorry, didn't see this in responding to your first comment.  ]
> 
> I think that's better than a static cast?

Done.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
File chrome/browser/download/chrome_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
chrome/browser/download/chrome_download_manager_delegate.cc:718: //
TODO(asanka): Merge this logic with the logic in DownloadFilePickerChromeOS.
On 2012/07/12 17:01:22, rdsmith wrote:
> Probably worth pulling Achuith into the review at some point, to keep him
> updated and in case he feels like taking this one.

Yeah. Hopefully we can get it down to a single GData path substitution instead
of two for a single download. The code change seems non-trivial so I wanted to
do it (or someone else should) on a separate CL.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/chr...
chrome/browser/download/chrome_download_manager_delegate.cc:793: //             
 persistable path after the DownloadFilePicker is done.
On 2012/07/12 17:01:22, rdsmith wrote:
> This is only for GData, right?  It should go away after we do the
> DownloadDetermination refactor.

Yeah. I didn't want to do it here since such a fix would become redundant once
the GData path substitution is refactored.

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/dow...
File chrome/browser/download/download_file_picker.h (right):

http://codereview.chromium.org/10704052/diff/7005/chrome/browser/download/dow...
chrome/browser/download/download_file_picker.h:37: // On ChromeOS,
DownloadItem::GetTargetPath is a temporary local filename.
On 2012/07/12 17:01:22, rdsmith wrote:
> I don't see the relationship of this comment to the following routine--is it
> stale?

It was stale. Fixed.

http://codereview.chromium.org/10704052/diff/7005/content/public/browser/down...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/7005/content/public/browser/down...
content/public/browser/download_manager_delegate.h:57: // possibly empty, target
path.
On 2012/07/12 17:01:22, rdsmith wrote:
> I'd like to say something about the state changes that are possible on the
> DownloadItem when calling this function.  I'd *like* the answer to be "none"
> (i.e. only used for external data/observers), but that doesn't allow the user
to
> cancel if prompted.  So I'll settle for documenting what can and can't happen.

> (Though if it appealed to you to update DownloadTargetCallback to allow
> propagating a cancel that way instead, I wouldn't object :-}.)

I made a note that the state of |item| shouldn't be changed save for external
data and changed the callback logic so that an empty target_path causes the
download to be canceled. This also means that unless a target path is specified,
the download would be implicitly canceled.

[asanka, 2012-07-18 21:58:45]

Randy: The test reworking added some non-trivial changes. Can you take a look at
the tests and download_test_observer.{h,cc}?

[Randy Smith (Not in Mondays), 2012-07-19 18:14:57]

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
File chrome/browser/download/download_test_observer.h (right):

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
chrome/browser/download/download_test_observer.h:18: namespace internal {
Where does the "namespace internal" pattern come from?  Did you invent it, or is
this used elsewhere in chrome?

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_close_browsertest.cc (right):

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_close_browsertest.cc:244: new
DownloadTestFileChooserObserver(second_profile_));
We do downloads in this test on incognito profiles as well; don't you need file
chooser observers for those too?

[asanka, 2012-07-23 19:47:10]

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
File chrome/browser/download/download_test_observer.h (right):

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
chrome/browser/download/download_test_observer.h:18: namespace internal {
On 2012/07/19 18:14:57, rdsmith wrote:
> Where does the "namespace internal" pattern come from?  Did you invent it, or
is
> this used elsewhere in chrome?

I thought it was a farly common C++ idiom that's used in Chrome:

$ git grep '^namespace internal' | wc -l
469

I changed the name of the delegate class to be less generic.

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/ui/browser_...
File chrome/browser/ui/browser_close_browsertest.cc (right):

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/ui/browser_...
chrome/browser/ui/browser_close_browsertest.cc:244: new
DownloadTestFileChooserObserver(second_profile_));
On 2012/07/19 18:14:57, rdsmith wrote:
> We do downloads in this test on incognito profiles as well; don't you need
file
> chooser observers for those too?

Done.

http://codereview.chromium.org/10704052/diff/31005/chrome/browser/download/do...
File chrome/browser/download/download_service.cc (right):

http://codereview.chromium.org/10704052/diff/31005/chrome/browser/download/do...
chrome/browser/download/download_service.cc:115: manager_delegate_ = NULL;
Will wait for http://codereview.chromium.org/10808054/

[Randy Smith (Not in Mondays), 2012-07-24 15:32:27]

LGTM, but do specifically run the browser closer tests (with
--gtest_also_run_disabled_tests) since they're mostly disabled and the try bots
won't run them (mostly).

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
File chrome/browser/download/download_test_observer.h (right):

http://codereview.chromium.org/10704052/diff/29001/chrome/browser/download/do...
chrome/browser/download/download_test_observer.h:18: namespace internal {
On 2012/07/23 19:47:10, asanka wrote:
> On 2012/07/19 18:14:57, rdsmith wrote:
> > Where does the "namespace internal" pattern come from?  Did you invent it,
or
> is
> > this used elsewhere in chrome?
> 
> I thought it was a farly common C++ idiom that's used in Chrome:
> 
> $ git grep '^namespace internal' | wc -l
> 469
> 
> I changed the name of the delegate class to be less generic.

Sounds good; just wasn't aware of that.

[asanka, 2012-07-24 19:46:03]

achuith: Can you take a look at the download_file_picker_chromeos.* changes?  In
addition, once this goes in we can rework the GData path substitution logic so
that it is only done once for a "Save as" download. Then we can persist the last
download path for GData downloads (currently ignored).

jam: Can you take a look at content/shell and content/public?

[jam, 2012-07-24 20:41:16]

lgtm

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
File content/public/browser/download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
content/public/browser/download_manager_delegate.cc:18: const
content::DownloadTargetCallback& callback) {
ditto

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:32: content::SavePageType,
nit: while you're here, remove all "content::" from this file

http://codereview.chromium.org/10704052/diff/31005/content/shell/shell_downlo...
File content/shell/shell_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/31005/content/shell/shell_downlo...
content/shell/shell_download_manager_delegate.cc:44:
content::DOWNLOAD_DANGER_TYPE_NOT_DANGEROUS,
nit: here and below, get rid of content::

[asanka, 2012-07-24 21:21:28]

Thanks!

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
File content/public/browser/download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
content/public/browser/download_manager_delegate.cc:18: const
content::DownloadTargetCallback& callback) {
On 2012/07/24 20:41:16, John Abd-El-Malek wrote:
> ditto

Done.

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
File content/public/browser/download_manager_delegate.h (right):

http://codereview.chromium.org/10704052/diff/31005/content/public/browser/dow...
content/public/browser/download_manager_delegate.h:32: content::SavePageType,
On 2012/07/24 20:41:16, John Abd-El-Malek wrote:
> nit: while you're here, remove all "content::" from this file

Done.

http://codereview.chromium.org/10704052/diff/31005/content/shell/shell_downlo...
File content/shell/shell_download_manager_delegate.cc (right):

http://codereview.chromium.org/10704052/diff/31005/content/shell/shell_downlo...
content/shell/shell_download_manager_delegate.cc:44:
content::DOWNLOAD_DANGER_TYPE_NOT_DANGEROUS,
On 2012/07/24 20:41:16, John Abd-El-Malek wrote:
> nit: here and below, get rid of content::

Done.

[achuithb, 2012-07-26 00:20:06]

lgtm.

Sorry for the delay

[asanka, 2012-07-26 16:20:39]

On 2012/07/26 00:20:06, achuith.bhandarkar wrote:
> lgtm.
> 
> Sorry for the delay

Thanks!

Added for TBR:

sky: chrome/browser/ui/browser_close_browsertest.cc

mirandac: chrome/browser/profiles/{off_the_record_,}profile_impl.cc

[commit-bot: I haz the power, 2012-07-26 16:24:03]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10704052/53001

[commit-bot: I haz the power, 2012-07-27 01:11:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10704052/59001

[commit-bot: I haz the power, 2012-07-27 02:31:24]

Change committed as 148703