Create an AndroidContentUriBlob (or similar) for DOM Files/Blobs corresponding to Android URIs
Categories
(Core :: DOM: File, enhancement, P3)
Tracking
()
People
(Reporter: asuth, Unassigned)
References
(Blocks 1 open bug)
Details
Bug 1807360 tracks an issue where, on Android, content URIs are first copied to a temporary blob for the purposes of nsIFilePicker-using APIs like <input type="file">, which is not great from a resource usage perspective for small-to-medium files and a major problem/source of failures for larger files. An initial proposed solution in that bug was to allow nsIFile/nsLocalFiles to resolve content URIs, but this is undesirable for layering perspectives, plus if we are able to have a File/Blob type that's explicitly aware of content URIs we can potentially do better with handling the spec concept of snapshot state by being able to use ContentResolve::registerContentObserver API to get an ContentObserver::onChange notification.
Note that during the discussion of how Blobs/Files might interact with this, we noticed that it's likely possible to avoid using the GeckoViewInputStream.h / GeckoViewContentProtocolHandler.h helpers if we use existing Gecko C++ file stream support (nsFileStreamBase in particular is what is aware of the file descriptors, nsFileInputStream may have too much nsIFile-specific support).
FilePickerDelegate.sys.mjs and the related kotlin glue code or successor/replacement would then want to be updated to create these blobs.
It may be appropriate to create Fenix/Android components bugs as well, but it's not immediately clear what component that would be, and we definitely do want a bug here in DOM: File for tracking this.
Note that bug 1899467 to clean up file picker remoting would also be necessary as well.
Description
•