Bugzilla

(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, 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 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](https://issuetracker.google.com/issues/77406791) 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` perm 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 a fair bit of additional work.

(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, 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 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](https://issuetracker.google.com/issues/77406791) 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` perm 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 a fair bit of additional work.

(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](https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd)), 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 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](https://issuetracker.google.com/issues/77406791) 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` perm 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 a fair bit of additional work.

(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](https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd)), 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](https://issuetracker.google.com/issues/77406791) 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` perm 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 a fair bit of additional work.

(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](https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd)), 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](https://issuetracker.google.com/issues/77406791) 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 a fair bit of additional work.

(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](https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd)), 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](https://issuetracker.google.com/issues/77406791) 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.