Opening files from external storage should be supported too.

RESOLVED FIXED in Firefox 66

Status

()

enhancement
P1
normal
RESOLVED FIXED
6 months ago
2 months ago

People

(Reporter: andrei.a.lazar, Assigned: JanH)

Tracking

Trunk
Firefox 66
All
Android
Points:
---

Firefox Tracking Flags

(relnote-firefox 66+, firefox66 verified)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Hardware: Unspecified → ARM
Version: unspecified → Trunk

Updated

6 months ago
Severity: major → normal
Priority: -- → P3

Updated

6 months ago
Priority: P3 → P1
Reporter

Comment 1

5 months ago
Trying to obtain the real path for a file located on the SD CARD will fail so we are going to
stream the data in a temporary file and make use of that path instead.
Attachment #9030239 - Attachment is obsolete: true
Assignee

Updated

5 months ago
Assignee: andrei.a.lazar → jh+bugzilla
Hardware: ARM → All
Assignee

Comment 2

5 months ago
Instead, getOriginalFilePathFromUri() will simply *always* return null if it
cannot divine the original file path, and consequently resolveContentUri() will
then always fall back to the temp file method if getOriginalFilePathFromUri()
returns null.
Assignee

Comment 3

5 months ago
Because getOriginalFilePathFromUri() doesn't use framework methods newer than
Kitkat, instead of a generic @SuppressLint("NewAPI") it would be better to use
@TargetApi(19), so you still get warned if you start using framework methods
more recent than API19.

However because the isKitkat helper variable is only used in one place, in the
end we simply replace it with a direct Build.VERSION.SDK_INT check, so that we
don't have to use any special handling for the linter.
Assignee

Comment 4

5 months ago
The AOSP ExternalStorageProvider always creates document IDs of the form
"storage device ID" + ':' + "document path", where the storage device ID will
be "primary" for the primary emulated storage and the file system UUID for
everything else.

Assuming that OEMs won't customise this behaviour, the main problem that needs
to be handled is how to turn the file system UUID back into a file system path.

Comment 5

5 months ago
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/242e66d84734
Part 1: Avoid exeception-based control-flow for resolving content://-URIs. r=snorp
https://hg.mozilla.org/integration/autoland/rev/fd078630d666
Part 2: Better API version linting. r=snorp
https://hg.mozilla.org/integration/autoland/rev/5651b431fe2c
Part 3: Guess ExternalStorageProvider file paths for non-primary volumes. r=snorp

Comment 6

5 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/242e66d84734
https://hg.mozilla.org/mozilla-central/rev/fd078630d666
https://hg.mozilla.org/mozilla-central/rev/5651b431fe2c
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66

Updated

5 months ago
Flags: needinfo?(sorina.florean)

Verified as fixed on latest Nightly build (67.0a1) and Beta build (66.0b3).

Flags: needinfo?(sorina.florean)

Release note added for 66: Added support to open files from external storage, such as an SD card.

Assignee

Comment 9

2 months ago

This bug was only about the built-in Android file explorer - with other file explorer apps or through manually browsing to the file location from within Firefox we have been able to open files on external storages for a long time. So I'm not sure this really warrants a release note, at least with this phrasing?

You need to log in before you can comment on or make changes to this bug.