>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/CAJJNyZazYBar9FccY%2B4T3U313CxG-Gpa-rzOWb3fMm2N1UKohw%40mail.gmail.com.
