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.
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
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?
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?
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”.
