I was happy to see this ship in the latest M132 release, but I ran in to another bug, so just as a heads up I'm linking it here: https://issues.chromium.org/issues/391283117
Ashley On Fri, 15 Nov 2024 at 00:43, Joel Hockey <joelhoc...@chromium.org> wrote: > From my testing, chromeos sets a default extension, but linux doesn't. > > Android doesn't support default extensions, but it does support setting > the default filename. I have created crbug.com/379140421 to set that via > showSaveFilePicker optional suggestedName field. > > On Thu, Nov 14, 2024 at 7:18 PM Ashley Gullen <ash...@scirra.com> wrote: > >> Just re-tried this and it's working a lot better in the latest Canary! >> Thanks for the fixes. >> >> One more issue I noticed though is that save prompts don't appear to add >> a default file extension. Using our PWA (https://editor.construct.net), >> create a new empty project and try saving it with Menu > Project > Save as >> > Save as single file. This uses showSaveFilePicker() passing an option >> like this: >> >> "types": [{ >> "description": ..., >> "accept": { >> "application/x-construct3-project": [".c3p"] >> } >> }] >> >> On Windows in the save prompt, type 'test' as the filename and save in >> the Documents folder, and it saves a file named 'test.c3p' (including the >> specified .c3p file extension). On Android if you do this it saves a file >> named 'test' with no file extension, whereas I expected it to also include >> the default file extension .c3p. Otherwise the user has to explicitly type >> in the file extension to save a file that is correctly identified by its >> file extension. >> >> On Wed, 13 Nov 2024 at 01:00, Mike Taylor <miketa...@chromium.org> wrote: >> >>> Thank you Joel for your work to enable this on Andoid and Webview, and >>> thanks to you and others for ensuring we ship quality features everywhere. >>> :) >>> On 11/12/24 6:54 PM, Joel Hockey wrote: >>> >>> The FileSystemAccess API is enabled for android and webview in M132 and >>> expecting to release to stable in Jan, 2025. >>> >>> Thanks to Ashley and others who have already tested, we have been able >>> to fix some missing pieces that were tricky for android. Please do let me >>> know if there are other issues or bugs. >>> >>> The blink-api-owners have approved shipping this API on android, and >>> suggested that PSA is sufficient for a case like this where an API already >>> exists on existing platforms. >>> >>> https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/YuZB8xHM3go/m/QdfbNRNUCAAJ >>> >>> >>> On Fri, Nov 1, 2024 at 10:56 PM Joel Hockey <joelhoc...@google.com> >>> wrote: >>> >>>> Ashley, I've got some fixes coming for the getFileHandle() call. I've >>>> been able to test with your app and it is working. I'm hoping to land them >>>> next week, but part of my change touches a lot of internal APIs, so review >>>> make take some time. >>>> >>>> Jeffrey, I think I've got the interop and compat better now, and if >>>> other devs find bugs, I'm hopeful that I can get code that can run >>>> unchanged on android. I've taken guidance from the Web Platform reviewer >>>> in launch/4341240 for doing this I2S. I'm not very familliar with the >>>> overall process, and I'm not sure what anyone is expecting in regard to >>>> LGTMs. I don't see any "Add Stage" button on the entry when I'm logged in. >>>> >>>> On Thursday, October 31, 2024 at 1:58:51 AM UTC+10 Jeffrey Yasskin >>>> wrote: >>>> >>>>> It seems like the "Interoperability and Compatibility" section for >>>>> this Intent is misleading: shipping a piece of an API can cause >>>>> compatibility problems if developers were feature-detecting the API as a >>>>> whole, and then a function is missing or doesn't work *after* they've >>>>> already committed to the "use the API" path. Do you have metrics for how >>>>> many sites will break like this? >>>>> >>>>> How do you intend developers to feature-detect the fraction of the API >>>>> that works on Android? If there's no good story for that, perhaps this >>>>> shouldn't ship until there is. (My sense matches Ashley's, that Android >>>>> doesn't actually support opening directories if it can't then open files >>>>> inside those directories, so perhaps the `showDirectoryPicker` function >>>>> should be omitted.) >>>>> >>>>> I also see that this re-used the overall File System Access Chrome >>>>> Status entry <https://chromestatus.com/feature/6284708426022912>, so >>>>> the API owners weren't prompted to actually LGTM it, and there are no >>>>> LGTMs >>>>> on this thread. The launch process doesn't explicitly describe the case of >>>>> adding some platforms to a shipped feature, but I think the right thing to >>>>> do is to click the "Add Stage" button at the bottom of the page, to add a >>>>> new "Prepare to Ship" stage, and then request API Owner review from that >>>>> stage. >>>>> >>>>> Jeffrey >>>>> >>>>> On Wed, Oct 30, 2024 at 3:55 AM 'Ashley Gullen' via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> Yes, we use dirHandle.getFileHandle(name, { create: true }). We use >>>>>> that to create new files in the chosen folder. That is fundamental to how >>>>>> our PWA saves data in folders (and I'd have thought fundamental to the >>>>>> use >>>>>> of a directory picker). >>>>>> >>>>>> On Wed, 30 Oct 2024 at 08:40, Joel Hockey <joelh...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> I've got fixes for mime-types and save-as. >>>>>>> >>>>>>> Ashley, I tried out the app and saw how it fails for "save as >>>>>>> project folder". I haven't looked at the JS code you have, but I'm >>>>>>> guessing that the problem is that the android implementation of >>>>>>> FileSystemHandle is missing some features such as >>>>>>> dirHandle.getFileHandle(name, {create: true}) >>>>>>> >>>>>>> >>>>>>> https://fs.spec.whatwg.org/#dom-filesystemdirectoryhandle-getfilehandle >>>>>>> >>>>>>> Android uses content-URIs for file paths, which don't work the same >>>>>>> as posix paths where you can append files inside a parent dir. I'll >>>>>>> take a >>>>>>> look at this more and see what we can do, but a lot of things in android >>>>>>> depend on both the APIs available and which file providers have >>>>>>> implemented >>>>>>> them and how. >>>>>>> >>>>>>> Can you confirm if you are using getFileHandle() or if you are able >>>>>>> to detect which specific call is failing? >>>>>>> >>>>>>> On Tue, Oct 29, 2024 at 9:00 PM Thomas Steiner <to...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Re 'save as folder': yes, it's just showDirectoryPicker({ mode: >>>>>>>>> "readwrite" }). We just describe that as "save as" in our own UI (as >>>>>>>>> it >>>>>>>>> basically means "choose the location with a dialog"). My main point >>>>>>>>> is that >>>>>>>>> things that work on desktop Chrome aren't currently working on >>>>>>>>> Android. >>>>>>>>> >>>>>>>> >>>>>>>> Gotcha, thanks for the clarification. So it was as I expected… :-) >>>>>>>> You didn't magically discover `showSave*Directory*Picker()`, >>>>>>>> which, actually, is a feature request >>>>>>>> <https://github.com/WICG/file-system-access/issues/431>. Apart >>>>>>>> from the semantically confusing Open vs. Save in the UI (below on >>>>>>>> macOS), >>>>>>>> your workaround actually gets us more than half-way there… >>>>>>>> >>>>>>>> [image: Screenshot 2024-10-29 at 11.58.00.png] >>>>>>>> [image: Screenshot 2024-10-29 at 11.58.17.png] >>>>>>>> >>>>>>> -- >>>>>> >>>>> 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+...@chromium.org. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73i39OZpMQyhM9hC5zgdw0B0fs2OQhJxWn9Yc%2B9adWh36w%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73i39OZpMQyhM9hC5zgdw0B0fs2OQhJxWn9Yc%2B9adWh36w%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/CAJJNyZYU7UybVnAHsyK-6_GKbq48ZZbZWOGkVMMzfth4jn0KFQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJJNyZYU7UybVnAHsyK-6_GKbq48ZZbZWOGkVMMzfth4jn0KFQ%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/CAABs73j0PVmXEYN0xHf4-_xsYNQ2%2BoJz_YK6adG%2B_F%3DGY_-%3D2Q%40mail.gmail.com.
