Wow, that's fantastic news! I tried the feature on 132.0.6803.0 on Android VanillaIceCream with this demo <https://googlechromelabs.github.io/browser-fs-access/demo/> that uses the main window, a same origin iframe, and a cross origin iframe (the last one should not work).
- Opening a single file and multiple files works just fine. A slight user irritation was the camera and microphone permission, but it made sense once I saw the picker, which is a camera and the files icons. - File MIME type filters seem to be ignored. I filtered on images and texts, but could open a PDF. - Opening folders works just fine. You need to be careful to not open a too big folder. Attempting to open DCIM caused Canary to become unresponsive. - Saving seems to not work quite yet. While it did trigger the same picker with the files and the camera icons (the camera should probably not be there, it should just enter the files flow directly), there was in the end no obvious way for me to say "yes, save here", that is, some sort of file name dialog. Did I not understand what I needed to do? Amazing work. I suppose the rest is polish and already known issues. Cheers, Tom On Sat, Oct 26, 2024 at 1:06 AM Joel Hockey <joelhoc...@chromium.org> wrote: > The FileSystemAccessLocal feature has just been enabled for android in > M132. > > On Thu, Sep 5, 2024 at 7:30 PM Thomas Steiner <to...@google.com> wrote: > >> Very excited for this feature to come, it's a frequently requested gap so >> far—frequently enough to link to the FSA for Android bug from our >> developer-facing documentation >> <https://developer.chrome.com/docs/capabilities/web-apis/file-system-access#:~:text=Support%20for%20Android%20is%20being%20worked%20on%20in%20the%20context%20of%20crbug.com/1011535.> >> . >> >> >>> There is one area where I am considering proposing a change to the spec >>> that showOpenFilePicker() could take a boolean hint to indicate the >>> intention of whether files are intended for read-only vs writable which >>> would allow Android to choose between Intent GET_CONTENT (read-only, but >>> supported by more providers) vs OPEN_DOCUMENT (allows for writing to files, >>> but not supported by as many providers). >>> >> >> I've just commented on a relevant GitHub issue >> <https://github.com/WICG/file-system-access/issues/302#issuecomment-2331041290> >> and >> tagged you. >> > -- Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 ----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.4.3 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181. ----- END PGP SIGNATURE ----- -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3D05USBgLCdEgg3k9bcxB%2BzU3YXpXU9i8egymV3KJLQbA%40mail.gmail.com.
