Prefer opening PDF downloads in the browser.

chrome/browser/download/download_item_model.h

Index: chrome/browser/download/download_item_model.h
diff --git a/chrome/browser/download/download_item_model.h b/chrome/browser/download/download_item_model.h
index 5a2c141ac5679a9574a37c83692566ff77391cff..05a1023f5c32b653a665c9e4e71539f078a632e1 100644
--- a/chrome/browser/download/download_item_model.h
+++ b/chrome/browser/download/download_item_model.h
@@ -126,6 +126,18 @@ class DownloadItemModel {
   // Change what's returned by ShouldNotifyUI().
   void SetShouldNotifyUI(bool should_notify);
 
+  // Returns |true| if opening in the browser is preferred for this download. If
+  // |false|, the download should be opened with the system default application.
+  bool ShouldPreferOpeningInBrowser() const;
+
+  // Change what's returned by ShouldPreferOpeningInBrowser to |preference|.
+  void SetShouldPreferOpeningInBrowser(bool preference);

[Randy Smith (Not in Mondays), 2013/11/04 19:53:26]

As gestured at in the high level comment, an alternative to this implementation
would be to store the target path mime type in the download item, and make the
determination of whether or not we should be opening using a platform handler a
pure functional check at all points at which we need the information.  In some
sense that'd be equivalent to this implementation, as DownloadItemModel just
uses user data to store information associated with the DownloadItem.  So it's
an aesthetics preference.  But I don't really think of
"ShouldPreferOpeningInBrowser()" as a pure UI preference; it's derivative of
other non-UI issues, and how "Open" is implemented isn't really about the UI. 
And target path mime type is indeed information associated with the download
(destination).  But I'm not requesting the change; it's something of an
aesthetic preference, and if I saw the other code maybe I wouldn't like that
either :-}.  But I figured I'd raise the possibility for your consideration.

[asanka, 2013/11/04 21:20:11]

It's a valid point.

However, the deciding whether a something should be opened in the browser based
on the MIME type isn't trivial and requires consulting data that's not available
on the UI thread. That's why I opted to make the decision early and store it in
the DownloadItemModel. And since the decision itself didn't belong in //content
(responsibility for opening a download is delegated to DownloadManagerDelegate
and hence to the embedder), I kept it in DownloadItemModel instead of adding it
to DownloadItem.

How the layering works for handling of 'open' is something that we'd need to
revisit when we are considering the componentization of downloads. But for now,
let me know if this addresses the issue you raise.

[Randy Smith (Not in Mondays), 2013/11/04 22:57:46]

Yes, it does; I hadn't fully groked that we were combining two pieces of
information (whether we wanted to open things in the browser == net supported
image type or .pdf, and whether we could open them securely == net supported
mime type or have a plugin loaded for them).

+
+  // Open the download using the platform handler for the download. The behavior
+  // of this method will be different from DownloadItem::OpenDownload() if
+  // ShouldPreferOpeningInBrowser().
+  void OpenUsingPlatformHandler();
+
   content::DownloadItem* download() { return download_; }
 
  private: