arc: Use the MIME type returned by the container to handle content URLs

components/arc/common/file_system.mojom

Index: components/arc/common/file_system.mojom
diff --git a/components/arc/common/file_system.mojom b/components/arc/common/file_system.mojom
index 24e4041ff8d137bc018b0cd52572b8b03c543433..6f0005fcc94afc5aa96a0b2af275c7d5269b27ac 100644
--- a/components/arc/common/file_system.mojom
+++ b/components/arc/common/file_system.mojom
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 //
-// Next MinVersion: 4
+// Next MinVersion: 5
 
 module arc.mojom;
 
@@ -51,7 +51,7 @@ interface FileSystemHost {
   [MinVersion=3] OnDocumentChanged@0(int64 watcher_id, ChangeType type);
 };
 
-// Next method ID: 8
+// Next method ID: 9
 interface FileSystemInstance {
   // Notes about Android Documents Provider:
   //
@@ -105,6 +105,11 @@ interface FileSystemInstance {
   // streams), -1 is returned.
   [MinVersion=1] GetFileSize@1(string url) => (int64 size);
 
+  // Asks the ContentResolver to get the MIME type of the file specified by the
+  // URL. When an error occurs, returns null value (not to be confused with the
+  // empty string).

[hidehiko, 2017/06/05 05:18:04]

Clarification: Can empty string be a valid returned value?
How about comment an example case when it happens?

[hashimoto, 2017/06/05 05:40:53]

This method returns the empty string when ContentResolver.getType() does that.
I don't think it happens with a sane ContentProvider implementation, so I don't
have a relevant example case in my mind.

"not to be confused with ..." part was added upon dcheng@'s request, but if it
has implications that the empty string is a valid MIME type, probably it's
better to remove that part from the comment?

[hidehiko, 2017/06/05 05:52:53]

Just IMHO:
Checked a bit more. According to RFC2045 Section 5.1, empty string is invalid
mime type.
It is common practice to use invalid data (like empty string, -1 or 0 for int,
etc.) for representing an error.
Though, if explicit optional type is preferred, I'm fine with it, too.

If I were you, I'd drop it, because it looks as if empty string has some valid
meaning, but actually not. Or,

"When an error occurs, returns null value (rather than empty string)."

to avoid empty string's validness implication?
Up to you.

[hashimoto, 2017/06/05 06:03:50]

OK, dropped that part.
Either in C++ (base::Optional<std::string>) or in Java (String), it should be
clear that a null value is different from the empty string.

+  [MinVersion=4] GetMimeType@8(string url) => (string? mime_type);
+
   // Establishes full-duplex communication with the host.
   [MinVersion=3] Init@5(FileSystemHost host_ptr);