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/7379b8ef-dffe-40f3-8322-c8982080ce35n%40chromium.org.
