- From: Evan Stade <notifications@github.com>
- Date: Wed, 30 Mar 2022 11:53:05 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/pull/1005/review/926529422@github.com>
@evanstade commented on this pull request.
Marcos, thank you for the thoughtful and constructive feedback. I've updated the PR, but due to the lack of signals from other vendors, for now we'll put this in manifest incubations.
> + |manifest_url|.
+ </li>
+ <li>If |file_handler| is failure, continue.
+ </li>
+ <li>[=list/Append=] |file_handler| to |processedFileHandlers|.
+ </li>
+ </ol>
+ </li>
+ </ol>
+ <p>
+ On [=installation=], a user agent SHOULD run the process to
+ [=register file handlers=]
+ </p>
+ <section>
+ <h3>
+ Registering file handlers
I don't think there's any _file type_ that we wouldn't want to allow access to. Access control should be applied to individual files that a user shouldn't be able to edit, as you say, by the OS. If a user is allowed to edit a file, I think there's a business justification for wanting to do it via a PWA. If we block specific file types from being edited, we run the risk of forcing apps/users to other ecosystems which don't have this restriction and are much less secure overall. And the greatest threat to user security/privacy is probably in the divulgence of PII or other secrets, which are more likely to be in .doc or .txt or .xlsx or .pdf than some obscure type --- these are clearly types we need to support.
> @@ -1209,6 +1209,148 @@ <h3>
conventions or limitations of the host operating system.
</p>
</section>
+ <section>
+ <h3>
+ `file_handlers` member
+ </h3>
+ <p>
+ The [=manifest's=] <code><dfn data-export="" data-dfn-for=
+ "manifest">`file_handlers`</dfn></code> member is a [=list=] that
done.
> @@ -1209,6 +1209,148 @@ <h3>
conventions or limitations of the host operating system.
</p>
</section>
+ <section>
+ <h3>
+ `file_handlers` member
+ </h3>
+ <p>
+ The [=manifest's=] <code><dfn data-export="" data-dfn-for=
+ "manifest">`file_handlers`</dfn></code> member is a [=list=] that
+ provides instructions for how the app handles file-opening actions
+ that originate outside of the app itself.
+ </p>
+ <p>
+ The management, presentation and selection of registered
done.
> + <p>
+ A user agent SHOULD <dfn>register file handlers</dfn> with the host
+ operating system, consistent with:
+ </p>
+ <ul>
+ <li>The app is exposed in appropriate OS surfaces such as the
+ native file browser and other surfaces that display lists of apps
+ that can handle a given file or file type.
+ </li>
+ <li>The app is a candidate for becoming the system's default
+ handler for associated file types.
+ </li>
+ </ul>
+ <p>
+ A user agent MAY truncate the total set of [=file extensions=] to
+ preserve functionality and prevent abuse.
fair enough, done.
> + </li>
+ <li>[=file handler/icons=]
+ </li>
+ </ul>
+ <p>
+ A user agent can use these members to associate the web application
+ with [=file type=] on the operating system.
+ </p>
+ <p>
+ A <dfn>file type</dfn> can be defined by a [=mime type=] and/or [=file
+ extension=]. A file belongs to a file type if the OS determines it to
+ have a mime type and/or its name ends with a certain [=file
+ extension=]. A <dfn>file extension</dfn> is a string that start with a
+ "." and only contains [=valid suffix code points=]. A <dfn>valid suffix
+ code point</dfn> is a [=code point=] that is [=ASCII alphanumeric=],
+ U+002B (+), or U+002E (.). Additionally, [=file extensions=] are are
done.
> + A user agent can use these members to associate the web application
+ with [=file type=] on the operating system.
+ </p>
+ <p>
+ A <dfn>file type</dfn> can be defined by a [=mime type=] and/or [=file
+ extension=]. A file belongs to a file type if the OS determines it to
+ have a mime type and/or its name ends with a certain [=file
+ extension=]. A <dfn>file extension</dfn> is a string that start with a
+ "." and only contains [=valid suffix code points=]. A <dfn>valid suffix
+ code point</dfn> is a [=code point=] that is [=ASCII alphanumeric=],
+ U+002B (+), or U+002E (.). Additionally, [=file extensions=] are are
+ limited to a length of 16 code points.
+ </p>
+ <aside class="note">
+ <p>
+ Note: These code points were chosen to support most pre-existing file
done.
> + "." and only contains [=valid suffix code points=]. A <dfn>valid suffix
+ code point</dfn> is a [=code point=] that is [=ASCII alphanumeric=],
+ U+002B (+), or U+002E (.). Additionally, [=file extensions=] are are
+ limited to a length of 16 code points.
+ </p>
+ <aside class="note">
+ <p>
+ Note: These code points were chosen to support most pre-existing file
+ formats. The vast majority of file extensions are purely
+ alphanumeric, but compound extensions (such as .tar.gz) and
+ extensions such as .c++ for C++ source code are also fairly common,
+ hence the inclusion of + and . as allowed code points.
+ </p>
+ </aside>
+ <aside class="note">
+ <p>
I've deleted this text because I believe the idea of it is covered by the normative text under #registering-file-handlers
> + </aside>
+ <aside class="note">
+ <p>
+ The selection of an app to handle a file launch if there are multiple
+ apps registered for the file's [=file type=] is functionality left to
+ the operating system.
+ </p>
+ </aside>
+ <section>
+ <h3>
+ `action` member
+ </h3>
+ <p>
+ The [=file handler=]'s <code><dfn data-dfn-for=
+ "file handler">action</dfn></code> member is a <a>string</a> that
+ represents a relative URL of the [=manifest/start_url=] origin that
thanks for catching, done.
> + <p>
+ The [=file handler=]'s <code><dfn data-dfn-for=
+ "file handler">action</dfn></code> member is a <a>string</a> that
+ represents a relative URL of the [=manifest/start_url=] origin that
+ is [=manifest/within scope=] of a [=Document/processed manifest=].
+ This URL will be navigated to in the steps to [=execute a file
+ handler launch=].
+ </p>
+ </section>
+ <section>
+ <h3>
+ `name` member
+ </h3>
+ <p>
+ The [=file handler=]'s <code><dfn data-dfn-for=
+ "file handler">name</dfn></code> member is a <a>string</a> that
This suggestion errors to be displayed whereas the current format works as expected. Is there a problem with the current format?
> + The [=file handler/name=] is used to describe the file type in a
+ human readable format, and is typically only displayed in OS surfaces
+ (such as a file browser) if the web app has become the default
+ handler for that file type. It's most useful for custom file types.
done
> + "multiple-clients". If not provided, the default behavior matches
+ "single-client".
Which thing should link to which thing, specifically?
The definitions/behavior are in the next paragraph.
> + {{LaunchParams/files}} set to a {{FrozenArray}} of
+ {{FileSystemHandle}}s that correspond to the file paths named
+ by |files|.
+ </li>
+ <li>[=launch a web app=] with |params|.
+ </li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+ </ol>
+ </section>
+ </section>
+ <section data-cite="file-system-access permissions">
+ <h2>
+ Launch queue and launch params
This queue helps avoid races between app readiness and file handle readiness. If you tried to drag and drop a file into an app window milliseconds after launching it, it might very well do nothing.
@alancutter as owner of this API
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1005#pullrequestreview-926529422
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/manifest/pull/1005/review/926529422@github.com>
Received on Wednesday, 30 March 2022 18:53:47 UTC