Issue metadata
Sign in to add a comment
|
GetUserMedia doesn't fire if tab is in background
Reported by
francesc...@gmail.com,
Sep 29 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Steps to reproduce the problem: 1. open the file attached. It will prompt for a getusermedia after 5 seconds. 2. Immediately after opening the file, select another program like "Finder" or anything that is not Chrome. 3. Wait 6/7 seconds then click on chrome again. What is the expected behavior? The gum prompt should be there. What went wrong? The gum prompt it's kind of "lost". The only way to get it back is to select another TAB then click on the gum tab again. Did this work before? Yes 59 Does this work in other browsers? Yes Chrome version: 61.0.3163.91 Channel: stable OS Version: OS X 10.12.5 Flash Version: Only tested in mac os. Not reproducible on dev 63.
,
Sep 29 2017
I can reproduce on Chrome stable 61.0.3163.100 and Beta 62.0.3202.38 on Mac. Chrome Canary 63.0.3227.0 works fine. Cannot reproduce on any Chromium Mac version, so I couldn't easily bisect to find when it was broken and fixed again. On Linux it does not reproduce, but I could reproduce and bisect a related issue. If you run the supplied script, dismiss (but not block) the permission and reload the page a few times, after 3-5 tries the permission is rejected automatically, but the domain is not listed as rejected. This is a bug, as it should always ask for permission and is reproducible on ToT. This Linux issue might or might not have the same root cause as the Mac issue reported by francesco.durighetto@, but it can reproduce with the same script. I bisected it to the following range: https://chromium.googlesource.com/chromium/src/+log/1913d5748e9730be549efe5a3f2d2248c4a425de..a048528fb5c16d84d0b0dc8eb3d3384a61671812 There is a permissions UI related CL there: https://chromium.googlesource.com/chromium/src/+/02958eaa8c765b0bc65c020bb1dd1d1fd0792de0 The CL was landed in M61, so it matches francesco@'s report. Assigning this bug to timloh@, who authored the CL for further analysis and triaging. I made the test file available on https://guidou.github.io/delay.html for easier reproduction.
,
Oct 3 2017
The change where permission is rejected automatically after several dismisses, described in #2 is intentional. The bug described in #1 isn't intentional but is likely related to changes in the PermissionRequestManager. The reason it works on Canary is because we switched to views. timloh could you please have a closer look?
,
Oct 5 2017
In m62, there's a finch experiment. Passing --disable-features=CocoaPermissionBubbles on the command line will give you the behaviour that is default in m63, and doesn't have most of these issues. One related issue remains - Issue 771885
,
Oct 10 2017
I'm going to close as WontFix because at this point there's not much we can do. As said earlier, this works in M63 (due to MacViews), so it'll be fixed once that reaches stable. M62 is going to stable in about a week, which is too soon to be able to fix and merge. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by francesc...@gmail.com
, Sep 29 2017