Open modes (view vs. edit) and CLI arguments

[brettz9]

OS' have means to indicate whether a file open is meant to be sent to a viewer or an editor, and as such, this would be handy to have exposed to files opened from the desktop.

In addition this could conceivably be extended with arbitrary (namespaced) command line arguments being passed in to set up a default skin, or other behaviors which a web app might be inclined to support.

Apologies as just exploring this, but I didn't see mention of this in design docs or the explainer.

(I ask you please be aware that I have a disability with "brain fog", so despite my being able to do coding at my own pace, I am much more sharply limited in processing new info than I might give the impression.)

[mgiuca]

Hi Brett,

To my knowledge, the concept of a "verb" attached to a file association (e.g. "view" vs "edit") isn't something formal in operating systems, it's something that's done informally by applications.

The two major file association systems I've worked with (Windows and Linux/FreeDesktop) do not have a concept of a verb. They just associate file types (extensions or MIME types) with applications (.exe files, in the case of Windows) or command-line strings (in the case of Linux). So you can associate ".mp4" files with both a video editor and a video player, but the OS doesn't intrinsically know that one is an editor and the other is a viewer.

The two solutions I have seen for this, if one application has two different verbs, would be either:

1. Create two different "applications", e.g. "Edit with MyVideoApp" and "View with MyVideoApp". This makes it clear to the user what the two verbs are, but the OS doesn't technically know that they are the same app. Or
2. On Windows, insert special entries into the right-click context menu for files in Windows Explorer (e.g., 7-zip adds a bunch of compress and decompress options to the context menu). This is outside of the realm of file associations and into deeper OS modification.

Either way, given that the OS doesn't properly expose a "verb" primitive, I don't think it makes sense for the web to either.

Unless I'm missing something and certain OSes do expose verbs like this. Perhaps you can give some detailed examples of where you've seen this.

[brettz9]

Unless I'm missing something and certain OSes do expose verbs like this. Perhaps you can give some detailed examples of where you've seen this.

They do actually expose verbs, at least in Windows. See https://docs.microsoft.com/en-us/windows/win32/shell/fa-verbs . Wikipedia states this on a generic page about OSes (though it only gives example for Windows): https://en.wikipedia.org/wiki/File_association#Associations_and_verbs .

Either way, given that the OS doesn't properly expose a "verb" primitive, I don't think it makes sense for the web to either.

Beyond the fact that at least Windows does offer this, it is handy to be able to pass in CLI arguments as per my other request within this issue--and if not done as proper OS verbs (as would be ideal, especially to avoid opening an app which could only handle viewing and not editing), these could at least be supplied as CLI arguments to the app if that were to be implemented.

(Btw, if you're looking for inspiration, you might find my WebAppFind project of interest, including its to-dos, as I've given this kind of ability (and others related to it) quite a lot of thought. But thought I'd start with the addition I believe ought to make the most sense to add as an incremental improvement. Some other ideas go more far afield, like the ability to use a context menu within the browser to shuttle off a page or its content into a web app, with the ability for that web app being optionally granted the ability to POST back to the originally user-selected web app--like web intents perhaps but potentially reusing the same mechanism as file-handling to allow content to be editable out of the box from web as well as file sources. But I digress...)

[connorjclark]

Either way, given that the OS doesn't properly expose a "verb" primitive, I don't think it makes sense for the web to either.

The web's handling of user file's improves upon the security model of native OSes (ex: File System Access API defines user permissions for read and read-write). Why limit the web's capabilities wrt file association just because OSes don't give users a similar choice? Is parity with existing OSes a more central design goal than more granular security controls? (just trying to understand motivations here)

Having two separate PWAs for viewing and editing is not a good solution, especially when you consider the UI treatment things like tabbed display mode gives a PWA. If editing/viewing as separate apps, that would mean these tabbed UIs get opened as separate windows (vs. keeping read/write tabs all in the same application window).

[file/application special entries] This is outside of the realm of file associations and into deeper OS modification.

(reference)

This perhaps suggests a UI for cases where there are multiple applicable file handlers: if there is just one, show an Open option (the first defined handler is the default action). If more than one, then also have an expandable entry that lists all the handlers (label would have to be added to the file_handler entries). I'm assuming equivalent context menu extensions are possible on Mac/Linux...

I understand this is different on the OS-level (file association vs context menu extensions) but the semantics seem equivalent (as in, file_handlers seems like a good place to define file-associated context menu actions, just missing a label field).

Beyond the fact that at least Windows does offer this, it is handy to be able to pass in CLI arguments as per my other request within this issue

You can accomplish this with query parameters on the action URL field. However, the lacking capability here is that it seems (at least in Chrome) a PWA will only respect the first handler given. Ex:

"file_handlers": [
    {
      "action": "/create",
      "accept": {
        "application/x-binary": [".qst"]
      },
      "launch_type": "single-client"
    },
    {
      "action": "/play",
      "accept": {
        "application/x-binary": [".qst"]
      },
      "launch_type": "single-client"
    }
  ]

Will only open .qst files with /create:

It'd also be nice to specify read-only (make launch queue provide a File with read only access) so that this UI can be more accurate for PWAs that truly will only read data.

---

Just to summarize, because there's three different (closely connected) things here:

1. Multiple file handlers for the same extension ought to be possible in a single PWA
2. A title or label for a file handler would be necessary to disambiguate multiple handlers
3. If file_handlers entries can declare read/write capabilities, the browser can a) lock down what the app can do with the provided file (prevent overwriting) and b) allow for more specific browser UI messaging when opening a file (currently, it always warns the app will be able to edit the file, even if the app doesn't want to)

[mgiuca]

Sorry I had missed your reply from last year @brettz9 .

It's true that Windows has "verbs" as a concept (sorry I over-simplified). But that concept of "open", "edit" and "print" is kind of incompatible with the user selecting their own application to open with. Note in that page you linked, there is an "open" "edit" and "print" command, but if the defaults are not set up the way the user wants, their only choice is to go "Open with" and pick an app, and that can only choose an app to use with the "open" verb. I don't think there is any way, outside of direct registry modification, for the user to choose which app handles the "print" verb for a given file type.

So my original assessment stands: if not impossible, it is impractical on Windows for web apps to be able to handle multiple different verbs. There is no UI to expose it to the user. And I don't think there is on any other system either. And if there's no reasonable UI to expose it, it suggests that it is too complex to specify.

To @connorjclark 's question:

Why limit the web's capabilities wrt file association just because OSes don't give users a similar choice? Is parity with existing OSes a more central design goal than more granular security controls? (just trying to understand motivations here)

Yes, I believe it is when we're dealing with OS integration topics like this. When we design an API, our explainer must explore how it fits into the natural UI of operating systems in existence. We aren't designing in a vacuum; we're trying to join into existing operating systems. If we specify something that can't be used, then we're giving web designers tools that don't work, and I would rather we don't specify those at all. Furthermore, if no OS exposes a given primitive, it should be a clue to us as platform designers that it isn't a very helpful primitive, or is too complex for users to understand. (As an example, I don't want to individually configure {N file types × M verbs}.)

On the 7-zip example: what you're showing there is outside of Windows' file associations system. It's 7-zip manually inserting itself into the Windows Explorer context menu, to add more controls. That's something that some apps do if they want to add many verbs rather than just a simple "open". We could allow web apps to do this, but it would be a much more ambitious system with a lot more spoofing and compatibility concerns. (I don't think other OSes that I know of allow apps to insert menus into the file browser's context menu.)

[brettz9]

It's true that Windows has "verbs" as a concept (sorry I over-simplified). But that concept of "open", "edit" and "print" is kind of incompatible with the user selecting their own application to open with. Note in that page you linked, there is an "open" "edit" and "print" command, but if the defaults are not set up the way the user wants, their only choice is to go "Open with" and pick an app, and that can only choose an app to use with the "open" verb. I don't think there is any way, outside of direct registry modification, for the user to choose which app handles the "print" verb for a given file type.

So my original assessment stands: if not impossible, it is impractical on Windows for web apps to be able to handle multiple different verbs. There is no UI to expose it to the user. And I don't think there is on any other system either. And if there's no reasonable UI to expose it, it suggests that it is too complex to specify.

One reasonable UI would be to support it at least as a form of blessed command line argument (i.e., blessed to be used for app mode, while allowing other more arbitrary CLI args for other app-designated purposes). Then users could, besides at the command line, create shell scripts which opened their favorite web apps into its desired mode (as well as pass other initial configuration arguments to them, such as a desired theme or whatever). This might even allow alternative UIs to be built with file systems no longer innovating on their own.