Fix bug 69468: Drag download does not work if there is URL redirection involv...

chrome/browser/download/download_item.h

Index: chrome/browser/download/download_item.h
===================================================================
--- chrome/browser/download/download_item.h	(revision 71082)
+++ chrome/browser/download/download_item.h	(working copy)
@@ -188,6 +188,7 @@
   FilePath full_path() const { return full_path_; }
   void set_path_uniquifier(int uniquifier) { path_uniquifier_ = uniquifier; }
   GURL url() const { return url_; }
+  GURL original_url() const { return original_url_; }

[Paweł Hajdan Jr., 2011/01/13 08:47:59]

We try to avoid adding more accessors like this one.

[Randy Smith (Not in Mondays), 2011/01/14 19:43:21]

It's sorta like the difference between structures and classes; structures just
carry data around, but classes hide that data and present an abstracted view of
it.  There's no abstraction on top of any of the URLs, so I think direct set/get
accessors are appropriate.  This might suggest a useful refactoring, where the
pure, carried around data associated with the DownloadItem is exposed through a
separate interface (maybe returns a const struct blah&) or maybe even is somehow
a separate object, and DownloadItem is a more standard class, with abstractions
and lack of access to internal data members.  But that's not this CL :-}.

   GURL referrer_url() const { return referrer_url_; }
   std::string mime_type() const { return mime_type_; }
   std::string original_mime_type() const { return original_mime_type_; }
@@ -259,6 +260,9 @@
   // The URL from whence we came.
   GURL url_;
 
+  // The original URL before any redirection.

[Paweł Hajdan Jr., 2011/01/13 08:47:59]

Now we have three URLs, and it's super-easy to confuse them all. The difference
should be much better documented. Do we actually need all three?

[Randy Smith (Not in Mondays), 2011/01/14 19:43:21]

I agree with this.  I'd suggest changing the doc on url_ to "The URL from which
we are downloading", adding "... redirection by the server for this url" to the
doc above.

In terms of whether we actually need all three, it's a hard question to answer. 
I just spent some time with codesearch, and found that url_/url() is used for:
* download_util::CreateDownloadItemValue (-> DOM)
* AutomationProvider::GetDictionaryFromDownloadItem (which could be used in a
whole lot of ways--it's going to be hard to trace the uses of this down).
* DragDownloadFile::ModelChanged (the usage this CL is modifying)
* Browser::OnStartDownload(): Avoid showing the animation for downloads that are
extensions.
* OpenChromeExtension: Used for notification of extension install.

referrer_url_/referrer_url() is only used in two of the above locations: the
automation provider dictionary creation and OpenChromeExtension.  

Those usages make me nervous that we do indeed need all three, though possibly
we should use the original_url_ (added here) for some of them.

+  GURL original_url_;
+
   // The URL of the page that initiated the download.
   GURL referrer_url_;