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 <chris...@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+unsubscr...@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+unsubscr...@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/CAOMQ%2Bw__8Eb1pP25zatPvTorowARg-OB5BpVGSQiwfu2mnsFtw%40mail.gmail.com.
