Intent to Implement: File Handling

196 views
Skip to first unread message

harr...@chromium.org

unread,
Feb 14, 2019, 12:13:39 PM2/14/19
to blink-dev, ericwi...@chromium.org, Raymes Khoury


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

unread,
Feb 14, 2019, 1:00:04 PM2/14/19
to harr...@chromium.org, blink-dev, Eric Willigers, Raymes Khoury
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

unread,
Feb 14, 2019, 7:44:32 PM2/14/19
to PhistucK, harr...@chromium.org, blink-dev, Eric Willigers, Raymes Khoury
Yes, indeed.

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

Alex

rhal...@google.com

unread,
Feb 19, 2019, 4:16:03 AM2/19/19
to blink-dev, phis...@gmail.com, harr...@chromium.org, ericwi...@chromium.org, ray...@chromium.org, ada...@chromium.org
Please make sure this gets a privacy review.

Philip Jägenstedt

unread,
Feb 26, 2019, 8:03:15 AM2/26/19
to rhal...@google.com, blink-dev, PhistucK, harr...@chromium.org, Eric Willigers, Raymes Khoury, ada...@chromium.org
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

unread,
Feb 26, 2019, 8:05:07 AM2/26/19
to rhal...@google.com, blink-dev, PhistucK, harr...@chromium.org, Eric Willigers, Raymes Khoury, ada...@chromium.org
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

unread,
Feb 27, 2019, 12:28:26 PM2/27/19
to blink-dev, ericwi...@chromium.org, ray...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages