- From: Evan Stade <notifications@github.com>
- Date: Fri, 11 Feb 2022 13:34:32 -0800
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/pull/1005/review/880544385@github.com>
@evanstade commented on this pull request.
Hello @marcoscaceres @jakearchibald Daniel and I have done some load balancing and I will be working on this PR going forward. PTAL the latest version. I have attempted to respond to all outstanding comments.
> + "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
+ represents a name to be provided to the user's operating system for
+ use with "Open with..." UX flows. This MAY be replaced by the user
done.
> + 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
+ represents a name to be provided to the user's operating system for
+ use with "Open with..." UX flows. This MAY be replaced by the user
+ agent for privacy & security reasons.
fiddled with this section a bit.
> + <li>|item|["name"] [=map/exists=] and is not a [=string=].
+ </li>
+ <li>|item|["accept"] doesn't [=map/exist=].
+ </li>
+ <li>|item|["accept"] is not a [=dictionary=].
+ </li>
+ <li>|item|["accept"] is [=list/empty].
+ </li>
+ </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
seems to me it takes a URL
> + <li>If |mime_type_parsed| is not defined in [[rfc2046]], return
+ failure.
I've removed the rfc reference. The parse a mime type algorithm and the IANA-MEDIA-TYPES reference should be sufficient.
> + <pre class="idl">
+ [Exposed=Window] interface LaunchParams {
+ readonly attribute FrozenArray<FileSystemHandle> files;
+ };
+ </pre>
+ <section data-cite="Permissions">
+ <h2>
+ <dfn>files</dfn> attribute
+ </h2>
+ <p>
+ The {{LaunchParams/files}} attribute is a {{FrozenArray}} of
+ {{FileSystemHandle}}s. For every |file handle:FileSystemHandle| in
+ {{LaunchParams/files}}, the [=permission state=] for a descriptor
+ with {{FileSystemPermissionDescriptor/handle}} set to the |file
+ handle| and {{FileSystemPermissionDescriptor/mode}} set to
+ "{{FileSystemPermissionMode/"read"}} should be "granted".
updated
> @@ -72,6 +72,13 @@
"ios_saf",
],
},
+ localBiblio: {
thanks, removed.
> + <li>Set |manifest|["file_handlers"] to |processedFileHandlers|.
+ </li>
That leaves `|manifest|["file_handlers"]` as uninitialized if there's an early return. Is that OK?
This order is used in `shortcuts` and `related_applications`
> + </li>
+ <li>[=list/For each=] |entry:ordered map| of |json|["file_handlers"]:
+ <ol>
+ <li>Let |file_handler:ordered map| be [=process a file handler
+ item=] with |entry|, |manifest/start_url|, |manifest/scope|, and
+ |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
Can you clarify how you suggest the text here should change?
What you say is accurate, we may be parsing the manifest for a reason besides installation (e.g. to show the installation dialog). There are other possibilities as well. The user agent might not register these associations with the OS at installation time, but pop up a toast when the app is later launched to confirm the user wants the associations.
> + |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
If you are referring to "...user agent MAY prevent registered file handlers...", there is no way prevent this registration from becoming default in certain scenarios on certain operating systems. Of course, we could still change this to SHOULD given the "if the operating system allows it" caveat.
Operating systems typically don't prevent installed native apps from making themselves default for a file type, so it's quite possible to imagine a user agent which tackles the scariness of this API and others by making a lot of noise at web app installation time, i.e. add a lot of "ceremony" so users treat the action with as much care as they would with a native app. Although this is not Chromium's current approach that may change in the future. Thus our security folks feel that whether these actions are necessary depends on external factors not covered here, hence my preference for MAY.
> + files in the host operating system.
+ </li>
+ <li>If there are multiple registered handlers for a file, the OS
+ allows the user to select which app should open it, and also allows
+ the user to set a default app.
+ </li>
+ </ul>
+ <p>
+ A user agent MAY prevent registered file handlers from registering
+ as the 'default' file handler for a given type if the operating
+ system allows.
+ </p>
+ </section>
+ <section>
+ <h3>
+ Privacy consideration: Default [=file handler=].
done.
> + `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
+ represents a name to be provided to the user's operating system for
+ use with "Open with..." UX flows. This MAY be replaced by the user
+ agent for privacy & security reasons.
+ </p>
+ </section>
+ <section data-cite="MIMETYPE">
+ <h3>
+ `accept` member
+ </h3>
+ <p>
+ The [=file handler=]'s <code><dfn data-dfn-for=
Yes. This is why the file extensions are required. I've attempted to clarify the wording here.
The goal is greater consistency of user experience across OSes and user agents.
Because certain operating systems require mime types for the association (linux via xdg-mime), we enforce that site authors must provide mime types. Any attempt by the user agent to smartly map from extension to mime type or vice versa would cause different user agents to behave differently since the mappings would not be identical.
However, it's also enforced that the file extension matches what's provided in the manifest. This may happen at the OS level or at the user agent level. For example, `"text/*": [".txt"]` would not match a `.csv` file anywhere, even on Linux where the file is recognized to match that MIME type. This would cause different OSes to behave differently.
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1005#pullrequestreview-880544385
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/manifest/pull/1005/review/880544385@github.com>
Received on Friday, 11 February 2022 21:34:45 UTC