We should make it possible to query/grant permissions using DevTools. This could be used, for example, to observe the page requesting geolocation access and to accept/reject that request.
Also see https://bugs.chromium.org/p/chromium/issues/detail?id=546706 for discussion about a command line flag.
I think it only makes sense in headless mode. The desktop user interface of Chrome lets you set an "Always allow" using the page information box (lock or page icon next to the URL) to anything.
Owner: skyos...@chromium.org Status: Assigned (was: Available) Summary: DevTools: Make it possible to control permissions via protocol (was: Make it possible to control permissions via DevTools)
skyostil@: mind me assigning to you? open to reviewing a CL if you have one/
We would also like this for Lighthouse. Here's a rough strawman of potential API:
Methods like:
Permission.forceAllow(permissionType)
Permission.forceReject(permissionType)
Event for
Permission.permissionChanged: permissionType, status
And Permission.disable() would revert back to previously saved permissions.
We can introduce a new "Permission" domain handler on the chrome/browser level that would talk to chrome/browser/permissions/permission_manager.h. PermissionManager would need minimal changes for that.
But that would not work for headless. Sami, how were you planning to implement it?
The proposal in comment 6 seems pretty straightforward? I haven't heard anyone asking for this recently so it's fine to downprioritize, but I think we should still keep this open as a potential feature.
Lighthouse's usecase is already satisfied via `Log.startViolationsReport` and then listening to `Log.entryAdded` for an entry of:
> 'Only request geolocation information in response to a user gesture.'
If users want to know that a permission prompt was triggered and not attached to a user gesture... they're good.
If users want to know that a permission prompt was triggered after a click, they currently do not have a protocol-level feature for this.
--------
The other use cases would be someone wanting to write integration tests exploring multiple ways of accepting/blocking permissions.
I'm OK with waiting until we have a more solid customer.
> ...someone wanting to write integration tests
That's a strong use case that I think we should support, especially now with Puppeteer. Shops will want to do e2e testing and without a way to control permissions, it's hard to full test important features: PWA push notifications, a maps app that uses geolocation, multimedia app that uses the device apis.
Perhaps we should keep this open so people can star it? Already has 13 stars!
I agree with Eric.
I'm currently writing a map-application and in order to write Nightwatch-tests to test features happening on the map it would a good thing for the geolocation to work.
My 5c into this.
I would like to provide a few use cases for such an API :
- A developer implementing web push notifications on their web site can write tests to check whether a user is able to subscribe to and receive web push notifications.
- A developer integrating geolocation API requests, in their core product would also benefit, by being able to test the functionality.
Any feedback would be appreciated.
Another use case:
I was trying to setup some e2e tests (using Puppeteer) for an app that uses the getUserMedia API to request a video stream from the user's camera. This requires granting permissions, which I cannot do programmatically.
Another use case:
I'm implementing complex e2e tests too (with chrome headless) and I need to start microphone and video to make my tests pass.
The permission box appear but I've no way to accept permission programmatically...
With the new Clipboard API (https://developers.google.com/web/updates/2018/03/clipboardapi) any E2E test requiring simulating copy/paste events would require to access control permissions. I would love to see this implemented. Personally I'm using pupeteer and there's currently no way to emulate a paste event.
FWIW, this has also been asked for a fair bit for WebPageTest for perf testing apps that rely on location information.
I work around it on desktop by writing a prefs file set to always-allow location but that doesn't work on Android (and it would be nice to avoid the prefs hack).
Comment 1 by skyos...@chromium.org
, Jul 26 2016