Add GetURLForBrowserTab method to the external file system backend.

webkit/browser/fileapi/file_system_backend.h

Index: webkit/browser/fileapi/file_system_backend.h
diff --git a/webkit/browser/fileapi/file_system_backend.h b/webkit/browser/fileapi/file_system_backend.h
index b71c8cab06d7fce114b06a3ade098dff8084f165..5c203d6a967cca949f2036f9fb3549e15a8aa109 100644
--- a/webkit/browser/fileapi/file_system_backend.h
+++ b/webkit/browser/fileapi/file_system_backend.h
@@ -157,6 +157,10 @@ class ExternalFileSystemBackend : public FileSystemBackend {
   // path is not exposed by this provider.
   virtual bool GetVirtualPath(const base::FilePath& file_system_path,
                               base::FilePath* virtual_path) = 0;
+  // Gets the alternative URL for the entry. e.g. Google Drive URL for hosted
+  // documents. Returns empty URL if the entry does not have an alternatvie URL.
+  virtual void GetAlternativeURL(const storage::FileSystemURL& url,

[mtomasz, 2014/09/02 07:37:49]

I'm wondering if the alternative URL is generic enough to be in the interface
for every file system backend.

Is this used by Files app only? If so, then why not using
chrome.fileBrowserPrivate.getDriveEntryProperties() which provides urls such as
share url? I'm currently working on making
chrome.fileBrowserPrivate.getDriveEntryProperties() work for other backends than
Drive.

https://codereview.chromium.org/515033002/

WDYT?

[hirono, 2014/09/02 07:46:18]

We have another path to open drive files without using getDriveEntryProperties.

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...

The code is used when a user presses Ctrl+O in the browser and opens the drive
hosted documents.
The file selector dialog is Files.app, but Files.app does not know how to use
the selected file after closing the dialog, thus Files.app cannot return drive
URL here.

[mtomasz, 2014/09/02 08:32:06]

I see. How about adding a GURL field to SelectedFileInfo? We could pass the url
from Files app easily. In browser.cc we are converting a local path to GURL
anyway, so we could just skip this step if a url is provided in
SelectedFileInfo.

I'm thinking more, and actually GetAlternativeURL method in the backend sounds
not so bad. Would we use it to do an actual *redirection*? If so, then we
shouldn't skip csp/origin restrictions. Eg. when loading the file with
XMLHttpReader.

There may be other side effects, though. When we read from the hosted file using
fileapi, we would read real contents of the file, but if we use XMLHttpRequest,
then we will get a redirection, and read from the web. I'm not sure if we
actually permit to read from a hosted document, and what would happen.

If we decide to go with the GetAlternativeURL() then I think we should  clean it
up. First of all it doesn't make sense for any backends other than Drive and
FSP. How about renaming to ResolveBrowserURL() which would generate file:///...
for local files, and http://... for hosted files?

I'm still not very sure, so let's see what other folks think about it.

WDYT?

+                                 base::Callback<void(const GURL& url)>) = 0;
 };
 
 }  // namespace storage