Intent to Implement: File Handling

[harr...@chromium.org]

Contact emails

harr...@chromium.org, ericwi...@chromium.org, ray...@chromium.org

Explainer

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

Design doc/Spec

N/A

Summary

We want to provide a way for application to specify that they are able to handle files with given mime types or extensions and provide OS integration for opening these files.

Motivation

This clears the path for applications which read and modify files to be built on the web platform. Some examples:

• Image Manipulation Tools

• Computer Aided Design Applications

• Document Editors

Risks

Interoperability and Compatibility

Edge: Interest

Firefox: Interest

Safari: No signals

Web / Framework developers: Seems to be developer interest.

Ergonomics

This API will probably be used in conjunction with ServiceWorkers (e.g. to work out what window to open the file in). This introduces the possibility of some overhead when we start the ServiceWorker before we are able to focus a tab/window and open the file.

This API will likely make use of writable files, and service worker launch events, neither of which have shipped.

Activation

Developers should be able to make use of this feature immediately. Polyfilling will not be possible, as it requires OS integration.

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

Eventually, yes. In the short term, we intend to just add Chrome OS support. More platforms will be added over time (though Android WebView will probably never be supported).

Blink Bug

https://bugs.chromium.org/p/chromium/issues/detail?id=829689

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

[PhistucK]

Sounds like a variation of navigator.registerContentHandler?

☆PhistucK

--
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/0e019fe9-fc55-4912-b9b6-605187041288%40chromium.org.

[Alex Danilo]

Yes, indeed.

We removed registerContentHandler from the W3C HTML spec due to lack of two interoperable implementations.

Alex

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_LS7wEdGX6LQC56DQdjRLzisYFa2ht6CuiHM%2BUHnXT6jg%40mail.gmail.com.

[rhal...@google.com]

Please make sure this gets a privacy review.

[Philip Jägenstedt]

Looks like https://github.com/WICG/file-handling/blob/master/explainer.md
is the new home of this repo.

Given that registerContentHandler didn't pan out, do you think it'd be
a good idea to spell out in the explainer why that ultimately failed
and the differences in the new model? Is it that it's only available
to install web apps?

The interop risk here seems like it might be high if it depends on
other APIs which are also new. Are other vendors on board with the
dependencies here, or what is the risk that this is Chrome-only for a
long time after it's shipped?

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ceb795e9-2950-4ab4-a1d5-d21075e81bf8%40chromium.org.

[Philip Jägenstedt]

Also, an explainer of the basic design exists, so this might be a good
time to send the TAG review. That might take some time, and the design
doesn't need to be "finished" before the first round.

[harr...@google.com]

Given that registerContentHandler didn't pan out, do you think it'd be
a good idea to spell out in the explainer why that ultimately failed
and the differences in the new model? Is it that it's only available
to install web apps?

 

Does anybody have any history on why navigator.registerContentHandler didn't catch on? In this issue, it sounds like the implementations didn't conform to the spec and that there wasn't much cross browser interest.

The interop risk here seems like it might be high if it depends on
other APIs which are also new. Are other vendors on board with the
dependencies here, or what is the risk that this is Chrome-only for a
long time after it's shipped?

There are two other APIs that this will depend on

- Writable Files (Mozilla's position is defer)

- and a subset of the SW-Launch proposal (we don't have any explicit signals on this but a launch event is implicit in file handling).

There is definitely interop risk here (and we're doing our best to engage with other browsers :)). This API wouldn't be useful without both writable files and some kind of launch event.