Thanks a lot, that's very helpful.

Cheers,
Titouan

On Tue, Apr 19, 2022 at 3:10 PM Evan Stade <est...@chromium.org> wrote:

> 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/CAPATO9cL_V9CGFiK%2BK%3DBeYRKsA%2BqP38LYsK5U-VeqY6nxQisuw%40mail.gmail.com.

Reply via email to