There have been some minor changes since OT in our implementation as described here[1] as well as bug fixes (largely addressing the OT feedback).
The only change to the API itself is the addition of the `launch_type` member which governs how multiple files are launched when they're launched simultaneously --- either all in one window, or each in their own window. [1] https://github.com/w3ctag/design-reviews/issues/371#issuecomment-1022586011 -- Evan Stade On Tue, Apr 19, 2022 at 4:11 AM Titouan Rigoudy <tito...@chromium.org> wrote: > Hi there, > > Has anything changed since the OT? > > Cheers, > Titouan > > On Tue, Apr 19, 2022 at 12:57 AM 'Ajay Rahatekar' via blink-dev < > blink-dev@chromium.org> wrote: > >> + Ajay Rahatekar >> >> On Monday, April 18, 2022 at 9:27:45 AM UTC-7 Chris Harrelson wrote: >> >>> On Mon, Apr 18, 2022 at 9:21 AM Evan Stade <est...@chromium.org> wrote: >>> >>>> On Fri, Apr 15, 2022 at 3:03 PM Chris Harrelson <chri...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 15, 2022 at 1:47 PM Evan Stade <est...@chromium.org> >>>>> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> est...@chromium.org, dmu...@chromium.org >>>>>> >>>>>> Explainer >>>>>> >>>>>> https://github.com/WICG/file-handling/blob/master/explainer.md >>>>>> >>>>>> Specification >>>>>> >>>>>> >>>>>> https://wicg.github.io/manifest-incubations/index.html#file_handlers-member >>>>>> >>>>>> Design docs >>>>>> >>>>>> https://tinyurl.com/file-handling-design >>>>>> >>>>>> Summary >>>>>> >>>>>> File Handling provides a way for web applications to declare the >>>>>> ability to handle files with given MIME types and extensions. The web >>>>>> application will receive an event when the user intends to open a file >>>>>> with >>>>>> that web application. >>>>>> >>>>>> >>>>>> Blink component >>>>>> >>>>>> UI>Browser>WebAppInstalls>FileHandling >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls%3EFileHandling> >>>>>> >>>>>> Search tags >>>>>> >>>>>> files <https://chromestatus.com/features#tags:files>, file handling >>>>>> <https://chromestatus.com/features#tags:file%20handling>, mime >>>>>> <https://chromestatus.com/features#tags:mime> >>>>>> >>>>>> TAG review >>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/371 >>>>>> >>>>> >>>>> The review performed was an early one almost 2 years ago. I've >>>>> reopened this issue so that the TAG can provide a full review. >>>>> >>>>> >>>>>> >>>>>> TAG review status >>>>>> >>>>>> Issues addressed >>>>>> >>>>>> Link to origin trial feedback summary >>>>>> >>>>>> >>>>>> https://plx.corp.google.com/scripts2/script_61._146b85_0000_2bae_bb88_001a114abbb8 >>>>>> >>>>>> Risks >>>>>> >>>>>> Interoperability and CompatibilityFails to become an interoperable >>>>>> part of the web if other browsers don't implement it. >>>>>> >>>>>> Sites can detect whether the feature exists, but polyfill or other >>>>>> fallbacks are unlikely to be possible or required. As this API is just >>>>>> one >>>>>> way to open a file in an app, apps will be able to open files with >>>>>> alternate means (such as <input type="file"> or drag and drop) regardless >>>>>> of the presence of this API. >>>>>> >>>>>> >>>>>> Gecko: N/A (https://github.com/mozilla/standards-positions/issues/629 >>>>>> ) >>>>>> >>>>>> WebKit: N/A ( >>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-April/032185.html) >>>>>> >>>>>> Web developers: Positive ( >>>>>> https://discourse.wicg.io/t/proposal-ability-to-register-file-handlers/3084/4) >>>>>> Already being prototyped by at least construct.net and excalidraw.com, >>>>>> based on https://crbug.com/1126091 and https://crbug.com/1131445. We >>>>>> also have a major partner that we can't publicly disclose. >>>>>> >>>>>> Other signals: >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> This feature relies on File System Access and the new >>>>>> LaunchQueue/LaunchHandler objects which are also to be used for >>>>>> `launch_handler`. No known performance risks. >>>>>> >>>>>> >>>>>> Activation >>>>>> >>>>>> Documentation and outreach will be helpful to understanding this API: >>>>>> https://web.dev/file-handling/ >>>>>> >>>>>> >>>>>> Security >>>>>> >>>>>> Please see the security model: >>>>>> https://docs.google.com/document/d/1pTTO5MTSlxuqxpWL3pFblKB8y8SR0jPao8uAjJSUTp4/edit >>>>>> >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> n/a (not a WebView feature) >>>>>> >>>>> >>>>> Please make sure this feature is explicitly disabled on WebView. >>>>> >>>> >>>> Certainly. Is there a standard way of doing that, or can we keep on >>>> relying on the feature flag? >>>> >>> >>> Here <https://chromium-review.googlesource.com/c/chromium/src/+/3565637> >>> is one example; it does require a bit of code on top of a Blink >>> RuntimeEnabledFeature. >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> File handlers are shown along with the rest of the manifest in the >>>>>> developer console in the "application" tab. Parsing errors are surfaced >>>>>> there. >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> Yes >>>>>> >>>>>> Flag name >>>>>> >>>>>> #file-handling-api >>>>>> >>>>>> Requires code in //chrome? >>>>>> >>>>>> False >>>>>> >>>>>> Tracking bug >>>>>> >>>>>> https://crbug.com/829689 >>>>>> >>>>>> Launch bug >>>>>> >>>>>> https://crbug.com/1284364 >>>>>> >>>>>> Non-OSS dependencies >>>>>> >>>>>> Does the feature depend on any code or APIs outside the Chromium open >>>>>> source repository and its open-source dependencies to function? >>>>>> >>>>>> n/a >>>>>> >>>>>> Sample links >>>>>> >>>>>> https://principled-ring-yarrow.glitch.me/ >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> OriginTrial last >>>>>> >>>>>> 94 >>>>>> >>>>>> OriginTrial first >>>>>> >>>>>> 92 >>>>>> >>>>>> DevTrial >>>>>> >>>>>> 92 >>>>>> >>>>>> Launch >>>>>> >>>>>> 102 >>>>>> >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> n/a >>>>>> >>>>> >>>>> Here you said "not applicable" but I think you mean there are no open >>>>> spec issues that would result in future compat or interop issues? >>>>> However, this >>>>> issue <https://github.com/WICG/file-handling/issues/70> is one such >>>>> example that is currently open. >>>>> >>>> >>>> Correct, there are no known/anticipated changes to the proposed spec. >>>> >>>> I don't think the linked issue would affect the API/spec itself. This >>>> seems like more of a marketing issue. That is, the only part of the actual >>>> API that might be relevant to the outcome of this issue is the manifest >>>> entry named "file_handlers" and I think that should retain its current >>>> name. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> >>>>>> https://chromestatus.com/feature/5721776357113856 >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> Intent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/y85xtaIpDH8/m/nHhOPG-iAAAJ >>>>>> >>>>>> Intent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Fb-NdCvbgmU >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Evan Stade >>>>>> >>>>>> -- >>>>>> 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 on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS-LkFMe4mV3O_y91dKEe_8EMa_7%2B62jBPE9ORsmCzeA%3Dg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS-LkFMe4mV3O_y91dKEe_8EMa_7%2B62jBPE9ORsmCzeA%3Dg%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+...@chromium.org. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS-9984hnZUbLEj1oftRwS5bTbCd1X%2BvX4da9piPFNB4iQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS-9984hnZUbLEj1oftRwS5bTbCd1X%2BvX4da9piPFNB4iQ%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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d1080ebd-de23-4981-855a-b7266f166779n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d1080ebd-de23-4981-855a-b7266f166779n%40chromium.org?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS8xwxUoHpF2rrcG1fmS%2B-xyZRoXdFSk-RT8PX%2BJ-GNPWQ%40mail.gmail.com.
