Thanks Tom and Ashley, I've created: crbug.com/376097107 - Android FileSystemAccess mime filters are being ignored crbug.com/376097630 - Android FileSystemAccess opening folder with many files causes chrome to become unresponsive crbug.com/376097108 - Android FileSystemAccess save-as does not allow creating a new file, only selecting existing crbug.com/376097631 - Android FileSystemAccess save as project folder fails
I don't think clank (chrome on android) currently has any code that does file-saveas, so the interface between chrome and the OS might not have all the required Intent options. I'll take a look at that and the other issues. Peter, apps that use webview will need to implement WebChromeClient#onShowFileChooser() for the JS code window.showOpenFilePicker() / showDirectoryPicker() / showSaveFilePicker(). I am working on adding more options to WebChromeClient.FileChooserParams to make it clearer when each is being used. The additional options will be available in a future (should be the next) API release. For permissions, the assumption is that if / when the app makes files available to JS code via onShowFileChooser(), the files are considered to have edit permissions. Any app that does not want to allow JS code to edit files should either not implement onShowFileChooser(), or should apply filtering. On Mon, Oct 28, 2024 at 10:57 PM Peter Beverloo <pe...@chromium.org> wrote: > Hi Joel, could you summarise how this has ended up working on WebView, as > there's neither permissions nor UI there? Will apps using WebView have to > adopt anything? > > Thanks, > Peter > > > On Mon, Oct 28, 2024 at 12:50 PM 'Ashley Gullen' via blink-dev < > blink-dev@chromium.org> wrote: > >> I'd be very happy to see the File System Access API ship on Android! >> However from my testing it doesn't look ready yet. Using our PWA Construct ( >> https://editor.construct.net) in Canary 132, create a new empty project >> and try saving it with Menu > Project > Save as, and: >> >> - Choosing 'Save as single file' shows a range of apps (some >> inappropriate including Camera) - choosing 'Files' then shows what appears >> to be a file picker. The aim here is to have a save-as operation and be >> able to choose a new file - but there doesn't seem to be any obvious way >> to >> choose a new filename here, it looks like you can only overwrite existing >> files. >> - Choosing 'Save as project folder' shows a folder picker right away. >> If I go to Documents, create a new folder named TestProject, tap 'Use this >> folder', approve the permission prompt (saying 'Allow'), and then approve >> a >> second permission prompt (this one saying 'Edit files'), it then shows an >> 'Unable to save project' error message. This appears to be because it >> throws 'InvalidStateError: An operation that depends on state cached in an >> interface object was made but the state had changed since it was read from >> disk.' >> >> These are basic use cases for the File System Access API in our PWA. >> Would be great if someone could take a look. >> >> >> On Mon, 28 Oct 2024 at 09:09, 'Thomas Steiner' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3D05USBgLCdEgg3k9bcxB%2BzU3YXpXU9i8egymV3KJLQbA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAABs73jsM-sOYMsapi%3DEdVQq0w7N8EgdzBn5afxTMaMg8Lf10w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jsM-sOYMsapi%3DEdVQq0w7N8EgdzBn5afxTMaMg8Lf10w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAJJNyZbxst31312QJLXtVGF%3DWCdsYnmUp96r6URJB-k1sadR3g%40mail.gmail.com.
