search

w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
336 stars 35 forks source link

Umbrella / Meta: Browser Permissions as an extension module #587

Closed thiagowfx closed 5 months ago

thiagowfx commented 8 months ago

Permissions spec umbrella issue: https://github.com/w3c/permissions/issues/424

"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:

Soft references:

css-meeting-bot commented 8 months ago

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/w3c/webdriver-bidi/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 commented 8 months ago

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 https://github.com/w3c/webdriver-bidi/issues/287#issuecomment-1802375543:

(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 commented 5 months ago

The recommendation was added (https://github.com/w3c/webdriver-bidi/pull/605), and the umbrella issue in the permissions repo was closed (https://github.com/w3c/permissions/issues/424), therefore this can be closed.

I'll just note that there's one missing AI from https://github.com/w3c/permissions/issues/424:

TODO: Add user context to SetPermissionParameters

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