- From: Evan Stade <notifications@github.com>
- Date: Fri, 24 Sep 2021 15:27:21 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/pull/1005/review/763495859@github.com>
@evanstade requested changes on this pull request.
> + without the explicit knowledge of the user. To protect against
+ possible mis-use, user agents MAY require explicit user consent to
+ begin with the process to [=execute a file handler launch=]. If
+ consent is denied, the user agent MAY remove the web application's
+ OS registration as a file handling entity.
+ </p>
+ </section>
+ <section>
+ <h3>
+ Privacy consideration: Name and icon.
+ </h3>
+ <p>
+ The name and icon of each file handler can be sensitive to privacy
+ and security, as there isn't a specified way for the user to see
+ and confirm these. Due to this, user agents MAY choose to replace
+ these with name and icon derived from the application's icon and
how about,
> MAY choose to ignore these in favor of alternative strings and icons.
For example, on Windows, if we have concerns about the file type name, we'd fall back to the default, which is FOO File (for the .foo extension).
> + OS registration as a file handling entity.
+ </p>
+ </section>
+ <section>
+ <h3>
+ Privacy consideration: Name and icon.
+ </h3>
+ <p>
+ The name and icon of each file handler can be sensitive to privacy
+ and security, as there isn't a specified way for the user to see
+ and confirm these. Due to this, user agents MAY choose to replace
+ these with name and icon derived from the application's icon and
+ name in the [=process a file handler item=] algorithm.
+ </p>
+ </section>
+ <aside class="example">
in the preview, this json comes out as poorly formatted for some reason. Should this follow the format of the "typical manifest" example, where it gets its own section and the explanatory text is outside of the example \<pre\>?
> + The [=file handler=]'s <code><dfn data-dfn-for=
+ "file handler">accept</dfn></code> member is a <a>dictionary</a>
+ mapping [=MIME types=] to a list of extensions. Extensions have to be
+ strings that start with a "." and only contain [=valid suffix code
+ points=]. Additionally extensions are limited to a length of 16 code
+ points.
+ </p>
+ <p>
+ In addition to complete [=MIME types=], "*" can be used as the
+ subtype of a MIME type to match, for example, all image formats with
+ "image/*". However, the top-level type MUST be defined in [[rfc2046]]
+ and listed in [[IANA_MEDIA_TYPES]].
+ </p>
+ <p>
+ Websites MUST always provide both [=MIME types=] and file extensions
+ for each [=file handler/accept=] entry. This format is required by
So technically, the file extensions don't matter on Linux (as long as the extensions and mime type are standard, like .csv and text/plain). Whereas on Windows, the MIME type shouldn't matter. So I would say this format is required to support the variety of operating systems, each of which may rely on MIME /or/ extension.
It's also required for custom extensions/MIMEs to tell Linux that a file ending in ".foo" is application/foo.
> + </p>
+ </section>
+ <section data-cite="MIMETYPE">
+ <h3>
+ `accept` member
+ </h3>
+ <p>
+ The [=file handler=]'s <code><dfn data-dfn-for=
+ "file handler">accept</dfn></code> member is a <a>dictionary</a>
+ mapping [=MIME types=] to a list of extensions. Extensions have to be
+ strings that start with a "." and only contain [=valid suffix code
+ points=]. Additionally extensions are limited to a length of 16 code
+ points.
+ </p>
+ <p>
+ In addition to complete [=MIME types=], "*" can be used as the
While the wildcard in the subtype would work in some OSes, on others only the extension matters. Thus it's probably worth noting that
`"image/*": [ ".png" ]`
would /not/ handle all image files on all OSes. (In fact there's no enforcement of these two lists having anything to do with each other, so
`"image/png": [ ".txt" ]`
would be accepted; it would just behave differently across OSes.
> + "name": "Comma-separated Value",
+ "accept": {
+ "text/csv": [ ".csv" ]
+ },
+ "icons": [
+ {
+ "src": "/csv-file.png",
+ "sizes": "144x144"
+ }
+ ]
+ },
+ {
+ "action": "/open-svg",
+ "name": "Image",
+ "accept": {
+ "image/svg+xml": ".svg"
nit: the file extension needs to be in a list
> + </ul>
+ </li>
+ <li>Let |url:URL| be the result of [=URL Parser|parsing=]
+ |item|["action"] with |start_url URL| as the base URL.
+ </li>
+ <li>If |url| is failure, return failure.
+ </li>
+ <li>If |url| is not [=manifest/within scope=] of |scope|, return
+ failure.
+ </li>
+ <li>Let |accept:ordered map| be an [=ordered map=].
+ </li>
+ <li>[=map/iterate=] |mime_type_string:string| → |extensions| of
+ |item|["accept"]
+ <ol>
+ <li>If |extensions| is not a [=string=] or [=list=], return
I don't think we intend to support a string that's not in a list?
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/manifest/manifest_parser.cc;l=1048-1057;drc=6fc55b5ee6ccec48d2e0ee47fb0e4bed0e1f8040
> + </li>
+ <li>If |mime_type_parsed|.type is not listed in as a top-level
+ type in [[IANA_MEDIA_TYPES]], return failure.
+ </li>
+ <li>Add |mime_type_string| → |extensions| to |accept|.
+ </li>
+ </ol>
+ </li>
+ <li>Let |file_handler:ordered map| be |ordered map| «[ "action" →
+ |url|, "name" → |item|["name"], "accept" → |accept| ]».
+ </li>
+ <li>[=Process image resources=] passing |item|["icons"],
+ |file_handler|, |manifest URL|, and "icons".
+ </li>
+ <li>The user agent MAY replace |file_handler|["icons"] with the
+ application icon.
Should it be this specific?
One proposal that has floated around before has been to use the application icon badged with the file type icon.
> + </section>
+ <section data-cite="file-system-access">
+ <h2>
+ <dfn>Execute a file handler launch</dfn>
+ </h2>
+ <p>
+ A {{Window/window}} has an associated {{LaunchConsumer}} <dfn>assigned
+ launch consumer</dfn>.
+ </p>
+ <p>
+ A {{Window/window}} has an associated [=list=] of {{LaunchParams}}
+ <dfn>unconsumed launch params</dfn>.
+ </p>
+ <p>
+ When a [=file type=] is registered with a web app and one or more of
+ these registered files are launched on the platform, run the following
these steps are also run after every same-origin page navigation (this supports refreshing the page or redirecting)
> + <section data-dfn-for="LaunchParams">
+ <h3>
+ <dfn>LaunchParams</dfn> interface
+ </h3>
+ <pre class="idl">
+ [Exposed=Window] interface LaunchParams {
+ readonly attribute FrozenArray<FileSystemHandle> files;
+ };
+ </pre>
+ <section>
+ <h2>
+ <dfn>files</dfn> attribute
+ </h2>
+ <p>
+ The {{LaunchParams/files}} attribute is a {{FrozenArray}} of
+ {{FileSystemHandle}}s.
worth noting these handles are read only? (but can be converted to readWrite via requestPermission)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1005#pullrequestreview-763495859
Received on Friday, 24 September 2021 22:27:34 UTC