[proposal] Ability to register file handlers

#1

= explainer

Operating systems give native applications a way to register their ability to handle files with given MIME types and/or file extensions. This has many use cases. An image editor might be able to display and edit a number of image formats. A movie player might understand a video format. A data visualizer might generate graphs from .CSV files. A Logo environment might interactively step through Logo programs.

Typically, the application might be activated when the user double clicks on a file, or right clicks on the file and chooses the application from a context menu.

Installed Web Applications should be able to have the same capability. They could use the manifest to declare which file types they handle, and receive a service worker event when activated. The explainer has more details.

#2

Blink is intending to implement this soon. Does anyone have any thoughts on the proposal, as it currently stands?

#3

Chrome Apps currently have the ability to register as handlers for folders. It would be great to have the same capability as part of this API.

https://developer.chrome.com/apps/manifest/file_handlers

This is what it looks like:

38%20PM
Screenshot 2019-02-06 at 10.29.38 PM.png2397×1247 156 KB

#4

It looks good to me - we’d like our web app Construct 3 to be able to open our own file format based on our own file extension (.c3p in our case). It looks like it should cover that.

One question I have is: after the new browsing context is opened, when exactly is the launch event fired on it? How do we know we’ve added our event listener in time? This is especially important with large PWAs that might do a lot of loading work beyond when the DOMContentLoaded/load events fire.

Is the FileSystemFileHandle passed writable, so the app can save changes back to the file system without additional prompts? That would be an excellent bonus.

#5

Sorry it’s been a few days guys. Thanks for the input!

@DanielHerr that would certainly be pretty useful (especially for something like VS Code), but I doubt it will make it into the first version of this spec. If we get writable directories with the writeable files it would be much more likely. Might be worth raising an issue on the repository though.

@AshleyScirra Firstly, I’m a big fan of Construct 3, it’s awesome! As to when and where the event will be fired, it’s not yet decided. I’m pretty partial to having the event handler defined on the ServiceWorker, but there’s an open issue here, some additional input and an explanation of what you need from the API would be great (and feel free to file issues for any other concerns/uses cases you think we should consider).

It’s definitely the intention that they be writable :slight_smile:

#6

The Github repository has been moved to WICG https://github.com/WICG/file-handling