+ 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.
