[proposal] Ability to register file handlers

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

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

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:

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

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.

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

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

Will this proposal provide a means to substitute using mpv or vlc for HTML <video> at a main thread (not a “Web App”) HTML document?

Could you clarify what you’re looking for please? It seems like your question can go one of two ways. The first, you want to know if VLC (for example) could be used to play video instead of the internal video player in a browser. The second way it reads, you’re wondering if this will let other native apps target your PWA for those file types to open it an play vs another native application using the OSes runtime.

Are either of those it? Or could you be looking for another answer?

Garbee18m

Could you clarify what you’re looking for please? It seems like your question can go one of two ways. The first, you want to know if VLC (for example) could be used to play video instead of the internal video player in a browser. The second way it reads, you’re wondering if this will let other native apps target your PWA for those file types to open it an play vs another native application using the OSes runtime.

Are either of those it? Or could you be looking for another answer?

In order to workaround several bugs in a given browser [Proposal] HTMLVideoElement Decode and Display Frame Resolution am trying to experiment with using a native executable that launches a native application, in this case mpv, entirely supplanting and replacing the browser internal Media Decoder and Web Media Player => HTMLVideoElement https://github.com/Kagami/mpv.js/issues/16#issuecomment-504750907 for the explicitly set MIME types (“file handlers”), e.g., video/webm<codecs=any>, and further video/*.

For example, a concrete use case is that Chromium is capable of generating Matroska files with codecs set to h264 or avc1 (video/x-matroska;codecs=<h264|avc1>) - and is capable of playback of the file types that the browser produced itself at HTML <video> element when explicitly set at the element src - yet prompts the user to download the file when navigated to https://bugs.chromium.org/p/chromium/issues/detail?id=999580 .

The context is the main thread, not an extension or “Progressive Web App”.