Asking for permission

[annevk]

I think it would be better if the permission request is tied to query(). The end user flow I envision is that the website invokes query() and the user then gets a browser-driven dialog with which they can select zero or more fonts to expose to the website.

(Aside: Mozilla is not interested in navigator.permissions.request() and it's not even part of Permissions.)

[oyiptong]

Given that permissions.request() is not yet implemented, the current implementation works similarly to what you describe.

A permission request is best done asynchronously.

navigator.fonts.query() returns synchronously. It returns an async iterator. So, it's not a good opportunity to place it there.
The current implementation as of today in chromium requests the permission on the first iteration, which is async.

What are your thoughts about this?

---

Alternatively, exploring an explicit permission request, what do you think of a navigator.fonts.requestPermission() API?

This is in the absence of navigator.permissions.request().

The reasoning to make this an explicit request would decouple the async iterator request with a permission requests and therefore makes a worker implementation more palatable.

It seems developer-hostile to get developers to call navigator.fonts.query() in a window, and triggering an enumeration, which might be an expensive operation, if what they want to do is do the enumeration in a worker.

[tomayac]

Alternatively, exploring an explicit permission request, what do you think of a navigator.fonts.requestPermission() API?

I'd rather prefer FontManager.requestPermission() similar to DeviceMotionEvent.requestPermission(), Notification.requestPermission(), and IdleDetector.requestPermission().

[annevk]

It depends, one thing that wasn't clear to me is whether an async iterator is warranted (see #32). Are there concrete plans to expose this in workers?

[oyiptong]

RE: the async iterator, I'll give it some thought and respond on #32

RE: exposing to workers, there aren't concrete plans as of yet.

However, the developers we've been obtaining feedback from want to use the data obtain from the API in workers.
It's a thing I'm keeping in mind wrt the API shape.

Do you see concerns exposing this in workers?

[annevk]

The potential problem I see is with the UI flow. I think ideally the user is empowered to chose what fonts end up exposed. And although that remains possible if you separate the permission prompt from the query, it all becomes a bit indirect.

[mgivan]

With the font dialog picker things may get more complicated when the tool is collaborative. A designer may select an initial set of fonts and the others should have a way to accept that list. During design the other collaborators (or even him) may want to change that initial set. A new font added into the system should generate user activation/permission requests for all the users involved. I feel that such amount of approvals that need to be given would make the application unattractive.
The user activation + permission request seems to be a more user friendly way to enable font usage and the font dialog picker can be the fallback solution for the users who are not comfortable to give the local-fonts access permission and they want to have a more granular control of which fonts are exposed to the web app.

[inexorabletash]

The API was change d so that permission is requested during query() as suggested.

https://wicg.github.io/local-font-access/#dom-fontmanager-query

[annevk]

Thanks, that's great!