1516467 - content://-URI protocol handler

Status: RESOLVED DUPLICATE of bug 1815739

(GeckoView :: General, enhancement, P3)

Description

[Jan Henning [:JanH]]

Currently, only Fennec supports opening content://-URIs, and even that is done somewhat hackily by patching into the unknown protocol handling in the ContentDispatchChooser [1] and IntentHelper [2].

It would be better to have this as a real protocol handler, so that
a) this works for all GeckoView-based apps, and
b) so that we can just stream the results of getContentResolver().openInputStream(contentUri) directly into our network stack instead of copying them to a temporary file first.

However I'd argue that before retrieving the file contents via getContentResolver().openInputStream(contentUri), just as today [3] we should still make an attempt to guess the actual file://-URI of the file behind the content://-URI [4]. While this is admittedly rather hacky and prone to breakage, unfortunately content://-URIs as Google currently implemented them are fundamentally broken for viewing content that implicitly depends on multiple files, such as locally saved web sites [5][6].


[1] https://hg.mozilla.org/mozilla-central/file/af22225148f7/mobile/android/components/ContentDispatchChooser.js
[2] https://hg.mozilla.org/mozilla-central/file/af22225148f7/mobile/android/base/java/org/mozilla/gecko/IntentHelper.java#l514
[3] https://hg.mozilla.org/mozilla-central/file/af22225148f7/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/ContentUriUtils.java#l50
[4] Assuming there is one, of course.
[5] A content://-URI only grants permission to the contents of a single specific file and therefore there's no way to access any other resources (images, style sheets, scripts, ...) required to properly render the file, navigate to a different document if the user clicked a link, etc. I've also written about that in bug 1406903, especially bug 1406903 comment 7.
[6] https://issuetracker.google.com/issues/77406791

Comment 1

[Chris Peterson [:cpeterson]]

Fenix will need this.

Comment 2

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #0)

However I'd argue that before retrieving the file contents via
getContentResolver().openInputStream(contentUri), just as today [3] we
should still make an attempt to guess the actual file://-URI of the file
behind the content://-URI [4]. While this is admittedly rather hacky and
prone to breakage, unfortunately content://-URIs as Google currently
implemented them are fundamentally broken for viewing content that
implicitly depends on multiple files, such as locally saved web sites [5][6].

Unfortunately, it seems that Android Q will make things rather worse here, though.
This is because as things currently stand, Google plans to ban general direct file system access for good. The resulting problems are manifold:

• Whereas today determined apps (like proper file explorers) can still launch other apps using file://-URIs if content://-URIs prove too limiting (ahem), and apps receiving such an Intent can still simply access that file if they have the READ_EXTERNAL_STORAGE permission, in the future no third-party app (unless perhaps using root on a rooted phone) will have direct general file system access, so likely everybody will have to switch to content://-URIs. As already mentioned, content://-URIs received from other apps unfortunately seem totally unsuitable for any content that doesn't consist of a single atomic file, though, for which HTML documents are a prime example.
• The READ_EXTERNAL_STORAGE permission is scheduled to be retired and (at least without root) there will be no direct file system access outside of the app-private directory and a few well-known folders accessible from the Context. The closet equivalent to READ_EXTERNAL_STORAGE would be prompting the user to pick a directory that the app may access via ACTION_OPEN_DOCUMENT_TREE.
  That in itself wouldn't be a major issue and could even be seen as a positive move to give users more control, but unfortunately, as things stand at the moment, that directory can then only be accessed via the Storage Access Framework, which is more cumbersome to use, less performant, has more limited features, doesn't integrate nicely with native code, etc. Especially the latter point means that Gecko's built-in file browsing capabilities won't work under the new system as is. So even if we do know where a file resides on the local storage, and the user did give us permission to access the relevant directory via ACTION_OPEN_DOCUMENT_TREE, actually loading the file might still not easily work, and listing a directory most certainly won't without what will likely be a fair bit of additional work.

Comment 3

[Chris Peterson [:cpeterson]]

Tasks and enhancements should have severity N/A.