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/CAABs73gkVd0-q%3D5k9osBu0tbAcsP7X5FCkiBZx0cWSj-%3D9CKGg%40mail.gmail.com.
