Umbrella / Meta: Browser Permissions as an extension module

[thiagowfx]

Permissions spec umbrella issue: w3c/permissions#424

• (optionally) add a recommendation about how external specifications should be authored (e.g., defining complete modules). I think we can leave the text about implementation extensions as is. It looks like there is nothing blocking on the WebDriver BiDi spec side: Introduce recommendations for external specification modules #605

"Interacting with Permissions for Powerful Features"

The WebDriver BiDi spec spec should support interaction with browser permissions as an extension module. These permissions represent a user's choice to allow or deny access to "powerful features" of the platform. For developers, the specification standardizes an API to query the permission state of a powerful feature, and be notified if a permission to use a powerful feature changes state.

The Permissions spec already supports WebDriver classic. This bug is about making it support WebDriver BiDi as well.

References:

• W3C Permissions spec: https://www.w3.org/TR/permissions/
• W3C Permissions repo: https://github.com/w3c/permissions/

Soft references:

• Meta: WebDriver BiDi extensions #506
• Extend roadmap: permissions automation #523

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Permission extensions.

The full IRC log of that discussion

<AutomatedTester_> Topic: Permission extensions
<AutomatedTester_> github: https://github.com//issues/587
<AutomatedTester_> orkon___: thiagowfx_web started looking into implementing permissions
<AutomatedTester_> ... there is a PR in draft that people can start reviewing about how extension methods should be written
<jgraham_> q+
<AutomatedTester_> ... do we want to refine the way we have extensions written or ...?
<AutomatedTester_> ack next
<AutomatedTester_> jgraham_: I haven't looked yet but adding whole modules seems a very clear way for people to add things
<AutomatedTester_> ... it also has good way to prevent people trampling over
<orkon___> q+
<AutomatedTester_> ... I think vendor extensions and spec extensions are very different use cases
<AutomatedTester_> ... we should encourage external specs to define whole modules for their use
<jgraham_> q+ gsnedders
<AutomatedTester_> ack next
<AutomatedTester_> orkon___: <describes something about colon>. As for classic permissions only has 1 command so that seems a little much for a whole module
<AutomatedTester_> ... but I think it could work
<AutomatedTester_> ack next
<jgraham_> q+
<AutomatedTester_> gsnedders: To use the permission spec as a idea... we should consider that a spec could extend webdriver and also want to add new capabilities and we should handle that
<AutomatedTester_> ack next
<AutomatedTester_> jgraham_: capabilities is a special case
<orkon___> q+
<AutomatedTester_> ... if the use case is extending capabilities I think that is already covered
<AutomatedTester_> ack next
<AutomatedTester_> orkon: we have already started looking into this to get the classic across to bidi. if you think we can improve this please comment on the PR
<AutomatedTester_> q?

[whimboo]

The Browser Testing and Tools Working Group just discussed Permission extensions.
The full IRC log of that discussion

And there was one more comment from @jgraham that actually sneaked into the logs for #287 (comment):

<jgraham_> (don't want to extend this topic further, but I always assumed BiDi would move to an event-based model for permissions i.e. you'd get a permissions.Request event with some information)

[thiagowfx]

The recommendation was added (#605), and the umbrella issue in the permissions repo was closed (w3c/permissions#424), therefore this can be closed.

I'll just note that there's one missing AI from w3c/permissions#424:

TODO: Add user context to SetPermissionParameters

@OrKoN you may want to open a separate bug/FR for that, if still relevant