Intent to Ship: File Handling

224 views
Skip to first unread message

Evan Stade

unread,
Apr 15, 2022, 4:47:21 PM4/15/22
to blink-dev

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


Search tags

files, file handling, mime


TAG review

https://github.com/w3ctag/design-reviews/issues/371


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 Compatibility

Fails 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)



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?

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


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.





-- Evan Stade

Chris Harrelson

unread,
Apr 15, 2022, 5:03:53 PM4/15/22
to Evan Stade, blink-dev
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


Search tags

files, file handling, 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 Compatibility

Fails 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.
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 is one such example that is currently open.
 

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.





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

Evan Stade

unread,
Apr 18, 2022, 12:21:35 PM4/18/22
to Chris Harrelson, blink-dev
Certainly. Is there a standard way of doing that, or can we keep on relying on the feature flag?
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. 

Chris Harrelson

unread,
Apr 18, 2022, 12:27:45 PM4/18/22
to Evan Stade, blink-dev
Here is one example; it does require a bit of code on top of a Blink RuntimeEnabledFeature.
 

Ajay Rahatekar

unread,
Apr 18, 2022, 6:57:39 PM4/18/22
to blink-dev, Chris Harrelson, blink-dev, Evan Stade, Ajay Rahatekar
+ Ajay Rahatekar

Titouan Rigoudy

unread,
Apr 19, 2022, 6:11:43 AM4/19/22
to Ajay Rahatekar, blink-dev, Chris Harrelson, Evan Stade
Hi there,

Has anything changed since the OT?

Cheers,
Titouan

Evan Stade

unread,
Apr 19, 2022, 9:10:13 AM4/19/22
to Titouan Rigoudy, Ajay Rahatekar, blink-dev, Chris Harrelson
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.

Titouan Rigoudy

unread,
Apr 19, 2022, 9:13:34 AM4/19/22
to Evan Stade, Ajay Rahatekar, blink-dev, Chris Harrelson
Thanks a lot, that's very helpful.

Cheers,
Titouan

Yoav Weiss

unread,
Apr 20, 2022, 9:29:33 AM4/20/22
to Evan Stade, Chris Harrelson, blink-dev
Why wouldn't we want the manifest entry to be renamed if the spec is renamed? 

 
 

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.





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

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

Evan Stade

unread,
Apr 20, 2022, 10:15:18 AM4/20/22
to Yoav Weiss, Chris Harrelson, blink-dev
I don't think the feature should be renamed. I tend to agree with mgiuca's argument. That is, "file handling" should have naming similar to procol handling (which is conceptually very similar) and launch_handler (which File Handling relies on heavily).

But either way, the manifest entry specifies the pages that handle specific file types. That is, "text/plain"/".txt" are handled by a particular page within the PWA. So I think "file_handlers" makes sense, because it's specifying what pages handle what files.

We've engaged with first party and third party partners, gone through TAG and spec review, and thus far only one person (the one who filed this) has taken issue with the name. So I don't think that broadly speaking it's confusing.

Thomas Steiner

unread,
Apr 20, 2022, 10:30:15 AM4/20/22
to Evan Stade, blink-dev
Hi Evan,

Updating our developer-facing documentation accordingly: https://github.com/GoogleChrome/web.dev/pull/7753. Happy to see this (hopefully) land very soon!

Cheers,
Tom

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


--
Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.comhttps://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----
Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
----- END PGP SIGNATURE -----

slightlyoff via Chromestatus

unread,
May 4, 2022, 11:44:20 AM5/4/22
to blin...@chromium.org
LGTM1

Yoav Weiss

unread,
May 4, 2022, 11:45:30 AM5/4/22
to blink-dev, slightlyoff via Chromestatus
LGTM2

On Wednesday, May 4, 2022 at 5:44:20 PM UTC+2 slightlyoff via Chromestatus wrote:
LGTM1

Chris Harrelson

unread,
May 4, 2022, 11:46:11 AM5/4/22
to Yoav Weiss, blink-dev, slightlyoff via Chromestatus
LGTM3

--
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.
Reply all
Reply to author
Forward
0 new messages