Intent to Experiment: File Handling API

[Darwin Huang]

Contact emails

huang...@chromium.org, c...@chromium.org

Explainer

https://github.com/WICG/file-handling/blob/master/explainer.md

(we’ll experiment with the entire API, but omitting icon support for now)

Specification

TBD. We’ll create this before an intent to ship.

Design docs

https://docs.google.com/document/d/13O71XW_WoQHzaE-53WxJ6-ciVUjAfzg6iedR2oEye7w 

(internal for now)

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 .

Risks

Interoperability and Compatibility

Fails to become an interoperable part of the web if other browsers don't implement it.

Gecko: Defer (early 2020). We’ll ask for a new position before intent to ship.

WebKit: No signal. We’ll ask for a position before intent to ship.

Web developers: Positive. 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.

Ergonomics

This will be used with file system access and installed PWAs often. No performance concerns from using File Handling in tandem with these APIs.

Activation

Documentation and outreach may be helpful, as this API is a bit complex (file handlers are registered with the OS during install-time, and launched by the user opening a file with the installed PWA after install).

Security

See the Security Model. The primary risks are spoofing and accessing files that shouldn’t be accessible.

Goals for experimentation

Information on API shape and usability.

Experimental timeline

We expect to start the Origin Trial in M91 (Stable on May 25, 2021)

Experiment timeline

M91-M93

Any risks when the experiment finishes?

No. At the end of OT, File handlers will be unregistered for sites that had them registered, but no information should be lost. Sites will simply no longer be able to open files using file handlers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. All desktop platforms (All blink platforms except Android and Android WebView)

Is this feature fully tested by web-platform-tests?

No. Manual and integration (browser) tests will be available as well for things that web-platform-tests cannot test, like OS-integration per platform and opening files on OS file managers.

Tracking bug

https://crbug.com/829689

Launch bug

https://crbug.com/1157254

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/y85xtaIpDH8/m/nHhOPG-iAAAJ

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5721776357113856

--

- Darwin Huang

[Darwin Huang]

+experimen...@chromium.org per OT instructions.

[Ashley Gullen]

Please note that while we (construct.net) are indeed keen to work with this origin trial, we are blocked on crbug.com/1126091, which I filed back in September. We will not be able to deploy this to users until that issue is fixed. I'd be happy to do testing and provide feedback if we are unblocked on that.

--
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/e42e8dfe-bb49-465c-9bbe-eaa44e40ecf6n%40chromium.org.

[Darwin Huang]

Thanks for following up on this and offering to help provide feedback, Ashley. We're currently working on implementing some permissions-related things right before OT, but we can aim to look into and fix https://crbug.com/1126091 by M92 (a milestone after OT).

On Tuesday, March 23, 2021 at 3:49:17 AM UTC-7 Ashley Gullen wrote:

Please note that while we (construct.net) are indeed keen to work with this origin trial, we are blocked on crbug.com/1126091, which I filed back in September. We will not be able to deploy this to users until that issue is fixed. I'd be happy to do testing and provide feedback if we are unblocked on that.

On Tue, 23 Mar 2021 at 00:27, Darwin Huang <huang...@chromium.org> wrote:

+experimentation-dev@chromium.org per OT instructions.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss]

On Tuesday, March 23, 2021 at 11:54:45 PM UTC+1 Darwin Huang wrote:

Thanks for following up on this and offering to help provide feedback, Ashley. We're currently working on implementing some permissions-related things right before OT, but we can aim to look into and fix https://crbug.com/1126091 by M92 (a milestone after OT).

On Tuesday, March 23, 2021 at 3:49:17 AM UTC-7 Ashley Gullen wrote:

Please note that while we (construct.net) are indeed keen to work with this origin trial, we are blocked on crbug.com/1126091, which I filed back in September. We will not be able to deploy this to users until that issue is fixed. I'd be happy to do testing and provide feedback if we are unblocked on that.

On Tue, 23 Mar 2021 at 00:27, Darwin Huang <huang...@chromium.org> wrote:

+experimentation-dev@chromium.org per OT instructions.

On Monday, March 22, 2021 at 11:38:00 AM UTC-7 Darwin Huang wrote:

Contact emails

huang...@chromium.org, c...@chromium.org

Explainer

https://github.com/WICG/file-handling/blob/master/explainer.md

(we’ll experiment with the entire API, but omitting icon support for now)

Specification

TBD. We’ll create this before an intent to ship.

https://www.chromium.org/blink/origin-trials/running-an-origin-trial#is-feature-ready requires a draft spec

 

Design docs

https://docs.google.com/document/d/13O71XW_WoQHzaE-53WxJ6-ciVUjAfzg6iedR2oEye7w 

(internal for now)

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 .

Risks

Interoperability and Compatibility

Fails to become an interoperable part of the web if other browsers don't implement it.

Gecko: Defer (early 2020). We’ll ask for a new position before intent to ship.

WebKit: No signal. We’ll ask for a position before intent to ship.

Web developers: Positive. 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.

Would  crbug.com/1126091 impact other partners as well?

[Darwin Huang]

Hmm, the origin trial link mentions that "a detailed explainer [...] may suffice"[1], and it seems that some intents to experiment often don't have draft specs. Is this a requirement for the i2e? Or does the explainer require more detail?

I'm not aware of any other partners that https://crbug.com/1126091 would impact

[1]: https://www.chromium.org/blink/origin-trials/running-an-origin-trial#sites-canvas-main-content:~:text=a%20detailed%20explainer%20laying%20out%20all%20the%20details%20may%20suffice

On Thursday, March 25, 2021 at 1:45:29 AM UTC-7 yoav...@chromium.org wrote:

On Tuesday, March 23, 2021 at 11:54:45 PM UTC+1 Darwin Huang wrote:

Thanks for following up on this and offering to help provide feedback, Ashley. We're currently working on implementing some permissions-related things right before OT, but we can aim to look into and fix https://crbug.com/1126091 by M92 (a milestone after OT).

On Tuesday, March 23, 2021 at 3:49:17 AM UTC-7 Ashley Gullen wrote:

Please note that while we (construct.net) are indeed keen to work with this origin trial, we are blocked on crbug.com/1126091, which I filed back in September. We will not be able to deploy this to users until that issue is fixed. I'd be happy to do testing and provide feedback if we are unblocked on that.

On Tue, 23 Mar 2021 at 00:27, Darwin Huang <huang...@chromium.org> wrote:

+experimen...@chromium.org per OT instructions.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Hi Darwin,

I agree that a formal spec is not needed for intent-to-experiment. A draft spec is ok (even if preliminary/rough), as is a well-developed explainer in cases where the API is relatively simple (as this one is, in my opinion). The main requirement, from my perspective, is that it's super clear what API shape is being experimented with, and how to use it. This requirement serves two important goals:

  (a) make sure everyone, especially those not working on the feature, can understand the relationship between the feature and the experiment's results

  (b) make it easy for sites to try out the experiment

I think your explainer is pretty close but not quite enough. Could you add in a fully developed explanation of all of the included APIs? Something like an inlined IDL or similar; In particular, it seems like the dictionary format that is put into the launchParams in your examples is not specified.

A demo app that exercises the feature would also be nice.

Second point: can you also make a public version of the design document?

Thanks,

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9bf4d9c-ff63-4a54-b157-534fec15f924n%40chromium.org.

[Thomas Steiner]

A demo app that exercises the feature would also be nice.

Maybe it helps you save some time: I have landed File Handling in excalidraw.com.

[Thomas Steiner]

On Wed, Mar 31, 2021 at 6:00 AM Tanmay Patange <tanmay....@gmail.com> wrote:

Can someone explain how File Handling API is different from Native File System API?

File Handling: doubleclick a file in the file explorer of the OS and an associated installed PWA opens (details).

File System Access (the new name for Native File System): let apps read and write files and directories (details).

[Tanmay Patange]

Can someone explain how File Handling API is different from Native File System API?

[Darwin Huang]

Thanks for the feedback, Chris. I've updated the file handling explainer with inlined IDL for the launchParams (and other launch-related) APIs. The only other site-facing API related to file handling should be the new manifest entries, which I hope are explained well enough already. Please let me know if the explainer should be more clearly defined anywhere.

I've made a public version of the design document available at https://tinyurl.com/file-handling-design 

Thank you for incorporating File Handling into excalidraw.com, Thomas! Another demo site is available at https://morning-bubbly-chauffeur.glitch.me/

[Alex Russell]

[ removing the larger mailing list ]

File Handling enables PWAs to receive files from actions in the OS (e.g., double-clicking on a document) while Filesystem Access (nee Native File System) lets users pick files and directories to share with the PWA once it has already launched. 

The operations that developers can take on the files are similar, but the actions users take are different.

Hope that helps.

On Wednesday, March 31, 2021 at 9:35:35 AM UTC-7 tanmay....@gmail.com wrote:

[Yoav Weiss]

Thanks for working on this PWA gap! :)

LGTM to experiment M91-M93

On Wednesday, April 7, 2021 at 10:58:59 PM UTC+2 Darwin Huang wrote:

Thanks for the feedback, Chris. I've updated the file handling explainer with inlined IDL for the launchParams (and other launch-related) APIs. The only other site-facing API related to file handling should be the new manifest entries, which I hope are explained well enough already. Please let me know if the explainer should be more clearly defined anywhere.

I think the explainer can still benefit from being a bit more explicit about what this feature does and how, and from slightly clearer structure.

The "motivation" part is great, but would benefit from a following one outlining what the proposal covers (e.g. "This proposal adds a new `file-handlers` array to the manifest, where each entry is a dictionary of the following format... It also adds a `window.launchQueue` method that enables the opened page to handle the files that were queued by the OS", potentially with some more detail)

The "example" covers what the manifest would look like, but would benefit from covering what one of the "open-X" pages may look like, and how it may use the launchQueue. (which you added below it, in the "Launch" section)

All this is non-blocking, but things that IMO can help folks experiment with the feature better get it out the gate.

[Darwin Huang]

(A very belated) thank you for the approval, Yoav!

Update: We unfortunately haven't completed implementation just yet, so we'd like to experiment in M92-M94 instead now.

I'll also make sure to update the explainer to be more explicit as the OT begins, per your last comment.

[Darwin Huang]

Hey Yoav, just wanted to confirm that experimenting in M92-M94 instead of M91-M93 sounds alright to you (or other API owners). Thanks!

[Yoav Weiss]

M92-M94 LGTM!