Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] [WebKit] The browser is appearing and asking to allow 'website' to use your camera and microphone, after running it in headless mode. #4959

Closed
elaichenkov opened this issue Jan 10, 2021 · 11 comments

Comments

@elaichenkov
Copy link
Contributor

elaichenkov commented Jan 10, 2021

Context:

  • Playwright Version: [1.7.1]
  • Operating System: [Mac]
  • Node.js version: [12.18.3]
  • Browser: [WebKit]
  • Extra: [macOS Catalina 10.15.7]
  pw:api => browserType.launch started +0ms
  pw:api <= browserType.launch succeeded +118ms
  pw:api => browser.newContext started +0ms
  pw:api <= browser.newContext succeeded +24ms
  pw:api => browserContext.newPage started +0ms
  pw:api <= browserContext.newPage succeeded +155ms
  pw:api => page.goto started +0ms
  pw:api navigating to "https://appr.tc/", waiting until "load" +1ms
  pw:api   navigated to "https://appr.tc/" +304ms
  pw:api   "domcontentloaded" event fired +272ms
  pw:api   "load" event fired +131ms
  pw:api <= page.goto succeeded +0ms
  pw:api => page.click started +0ms
  pw:api waiting for selector "#join-button" +3ms
  pw:api   selector resolved to visible <button id="join-button">JOIN</button> +22ms
  pw:api attempting click action +2ms
  pw:api   waiting for element to be visible, enabled and not moving +0ms
  pw:api   element is visible, enabled and does not move +26ms
  pw:api   scrolling into view if needed +0ms
  pw:api   done scrolling +1ms
  pw:api   checking that element receives pointer events at (511.19,240.35) +2ms
  pw:api   element does receive pointer events +2ms
  pw:api   performing click action +0ms
  pw:api   click action done +348ms
  pw:api   waiting for scheduled navigations to finish +0ms
  pw:api   navigations have finished +0ms
  pw:api <= page.click succeeded +1ms
  pw:api   "networkidle" event fired +505ms
  System:
    OS: macOS 10.15.7
    Memory: 98.62 MB / 16.00 GB
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash

Code Snippet

const { webkit } = require('playwright');

(async () => {
    const browser = await webkit.launch();
    const page = await browser.newPage();

    await page.goto('https://appr.tc/');
    await page.click('#join-button');
})();

Describe the bug
The browser is appearing and asking to allow 'website' to use your camera and microphone, after running it in headless mode.

Here is the screenshot in headless mode
image (1)

NOTE:
In headed mode, the browser doesn't ask you for these permissions and a fake video stream works by default without providing any arguments or granting permissions.

Here is the screenshot in headed mode
image (2)

Slack conversation.

@yury-s
Copy link
Member

yury-s commented Jan 11, 2021

Looks like it's macOS-specific, I can't reproduce it on Linux.

@yury-s
Copy link
Member

yury-s commented Jan 11, 2021

Can reproduce it on Mac, the headless window becomes visible and the dialog shows up on top of it.

@elaichenkov
Copy link
Contributor Author

Hey @yury-s
Thanks for the reply!
Btw, can you see the generated video in the headed mode on Linux?

@yury-s
Copy link
Member

yury-s commented Jan 14, 2021

Btw, can you see the generated video in the headed mode on Linux?

No, I also see TypeError: undefined is not an object (evaluating 'navigator.mediaDevices.getUserMedia') in the console.

@pavelfeldman
Copy link
Member

My understanding is that the bug is the opposite: it should query the permission in headed mode as well. And there should be a way to suppress the permission check via granting context user media permissions.

@yury-s
Copy link
Member

yury-s commented Mar 18, 2021

We currently don't support camera and microphone permissions in webkit. It's particularly hard in webkit because the implementation differs a lot between platforms (doesn't work on Windows for example) so we are not ready to add them at the moment. Without such permissions it's not clear what a meaningful fix for this bug would be, we could suppress the dialog and simply dismiss the dialog but that would fix just one step in the testing scenario and it still wouldn't be possible to test webrtc in a
sensible way. Considering little value of just suppressing the dialog I'm leaving this issue open until we decide to work on a more comprehensive support for webrtc (tracked in #2973).

@Kalliser
Copy link

Support camera and microphe is one thing, crash is another, on us.luivuitton.com all JS are broken because of this.
I fixed it using context :
currentContext.addInitScript('navigator.mediaDevices = { getUserMedia: function() { return newPromise((resolve, reject) => { reject("No media available") }) } }');

@akhil-kp-dasan
Copy link

async _grantPermissions(origin: string, permissions: string[]) {
const webPermissionToProtocol = new Map<string, string>([
['geolocation', 'geolocation'],
]);
const filtered = permissions.map(permission => {
const protocolPermission = webPermissionToProtocol.get(permission);
if (!protocolPermission)
throw new Error('Unknown permission: ' + permission);
return protocolPermission;
});
await this._pageProxySession.send('Emulation.grantPermissions', { origin, permissions: filtered });
}

@yury-s I can see that there is map of permissions supported by Webkit . Would it be possible to get camera and microphone permissions working on Mac simply by adding those permissions to that map or is there more to it than that?

@pavelfeldman
Copy link
Member

Why was this issue closed?

We are prioritizing the bugs based on the upvotes, recency and our ability to act. It looks like this issue only has a handful of upvotes, has not been touched recently and/or we lack sufficient feedback to act on it. We are closing issues like this one to keep our bug database maintainable. Please feel free to open a new issue and link this one to it if you think this is a mistake.

@RichFlickstein
Copy link

RichFlickstein commented Jun 2, 2022

@pavelfeldman I saw you closed this issue but we have not found a work-around. We have a app that requires these permissions and we'd like to test it with Playwright. Currently, we are using Protractor with Safari on Mac with BrowserStack and there are no issues there. Can you consider re-opening this and addressing it?

@domme1908
Copy link

domme1908 commented Sep 22, 2022

Hi, are there any news on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants