getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
People
(Reporter: arun3528, Assigned: haik, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
5.67 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Steps to reproduce:
https://janus.conf.meetecho.com/screensharingtest.html
https://www.webrtc-experiment.com/getDisplayMedia/
https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing
Tried all the above links but it leads to the same error
OS version macOS Catalina
Version 10.15.3
firefox version :72.0.2
Actual results:
WebRTC error:
MediaStreamError { name: "NotFoundError", message: "The object can not be found here.", constraint: "", stack: "" }
Share does not work
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Jan-Ivar, I think this is the bug that I mentioned in IRC. Could you take a look? I think bug 1611931 is a duplicate of this.
One thing to note . We have seen 72.0.2 working well on windows and older version of mac os.
I am guessing its specific to cantalina the new os
Comment 3•5 years ago
•
|
||
Arun, please let me know if bug 1606434 comment 1 fixes your problem.
Updated•5 years ago
|
I did try setting the permissions and tried but it lead to the same result. It shows the share popup screen then when you select the screen it throws an error on the console
Comment 6•5 years ago
|
||
Arun, sorry to hear it didn't work. Did you restart Firefox after setting the OS permission? (System Preferences -> Security & Privacy -> Privacy -> Screen Recording and check ☑ Firefox
) Please restart Firefox, and click the button on this test page. If that doesn't work I would try restarting the machine.
Am I understanding correctly that you are seeing Firefox's permission prompt asking you which window or screen to share, and when you pick a screen and click "Allow" you get NotAllowedError
? Is this still with 72.0.2?
If so, that is definitely odd, since as of 71 (bug 1588640) Firefox takes steps to check permission before deciding to show the prompt.
You mention 72, to rule out regression do you mean it worked for you in 71? (download link)
If all else fails, I'd try the steps in bug 1606434 comment 3 and restart firefox (maybe even the machine) afterwards.
Updated•5 years ago
|
Sorry jan. I tried all the above steps on 71 and 72 and it lead to the same results . I tried the command on the other bug. It cleaned the permissions out i added them back then tried still the same issue .
Let me know if you want to do a live debug we can join webex and check
Comment 8•5 years ago
|
||
I upgraded macOS from 10.15.2 to 10.15.3 and now I can reproduce. The OS update appears to break screen capture in all Firefox versions >70.
[Tracking Requested - why for this release]: Screen capture stopped working with macOS 10.15.3 update, but works in Chrome and Firefox <71.
Regression range:
14:57.28 INFO: Narrowed inbound regression window from [6e4fc5f0, 9de30d23] (3 builds) to [6e4fc5f0, 503c19dc] (2 builds) (~1 steps left)
14:57.28 INFO: No more inbound revisions, bisection finished.
14:57.28 INFO: Last good revision: 6e4fc5f02a5c013f525e96956e2c1a525d403a90
14:57.28 INFO: First bad revision: 503c19dcad61f4f0418c80880f8f05183abcd15e
14:57.28 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6e4fc5f02a5c013f525e96956e2c1a525d403a90&tochange=503c19dcad61f4f0418c80880f8f05183abcd15e
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
In Nightly it's failing here with PERMISSION_STATE_DENIED
:
OSPermissions.getScreenCapturePermissionState(scrStatus);
if (scrStatus.value == OSPermissions.PERMISSION_STATE_DENIED) {
getScreenCapturePermissionState was added in bug 1580900. Haik, any idea why this would stop working with 10.15.3?
Comment 10•5 years ago
•
|
||
This is getting weird. It's an hour or so later, and I can no longer reproduce, and screen capture mysteriously works again everywhere.
I'm no longer certain this is limited to 10.15.3, although I'd never seen this until I just upgraded.
Haik, I notice getScreenCapturePermissionState assumes we must be able to get the names of all enumerable windows, otherwise it returns PERMISSION_STATE_DENIED
.
Do we have any documentation we're ever guaranteed this? Might there be some occasional (new?) OS background window without name tripping us up?
Comment 11•5 years ago
|
||
I guess I did confirm it at one point, so it should be marked NEW.
Assignee | ||
Comment 12•5 years ago
•
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #9)
In Nightly it's failing here with
PERMISSION_STATE_DENIED
:OSPermissions.getScreenCapturePermissionState(scrStatus); if (scrStatus.value == OSPermissions.PERMISSION_STATE_DENIED) {
getScreenCapturePermissionState was added in bug 1580900. Haik, any idea why this would stop working with 10.15.3?
You can debug what's happening on release builds of Firefox by launching the browser with the following MOZ_LOG.
$ MOZ_LOG_FILE=/tmp/mozlog.nsCocoaUtils.txt MOZ_LOG=nsCocoaUtils:4,append,sync open /Applications/Firefox.app
Once you attempt to use screen recording, the logger should put some entries into /tmp/mozlog.nsCocoaUtils.txt.moz_log
. See example below from a test where Firefox didn't initially have screen recording permission when screen sharing was first tried and then permission was granted in macOS settings and then screen sharing was attempted again. Note the "3/38 named windows" resulting in "not authorized", then the "38/38" entry resulting in "authorized".
[Parent 86244: Main Thread]: D/nsCocoaUtils GetScreenCapturePermissionState() returned 38 windows
[Parent 86244: Main Thread]: D/nsCocoaUtils GetScreenCapturePermissionState(): 3/38 named windows
[Parent 86244: Main Thread]: D/nsCocoaUtils screen authorization status: not authorized
[Parent 86244: Main Thread]: D/nsCocoaUtils GetScreenCapturePermissionState() returned 38 windows
[Parent 86244: Main Thread]: D/nsCocoaUtils GetScreenCapturePermissionState(): 38/38 named windows
[Parent 86244: Main Thread]: D/nsCocoaUtils screen authorization status: authorized
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #10)
This is getting weird. It's an hour or so later, and I can no longer reproduce, and screen capture mysteriously works again everywhere.
I'm no longer certain this is limited to 10.15.3, although I'd never seen this until I just upgraded.
Haik, I notice getScreenCapturePermissionState assumes we must be able to get the names of all enumerable windows, otherwise it returns
PERMISSION_STATE_DENIED
.Do we have any documentation we're ever guaranteed this? Might there be some occasional (new?) OS background window without name tripping us up?
In the WWDC presentation it was explained how the window name is only available if screen recording permission has been granted. But I don't think there was any documentation explicitly stating that every window would have a name in this case. The window name is a heuristic that a few other projects were using in lieu of an API to check for screen recording.
I suspect you are right and there is a window violating the assumption making the check not work. It appears that Chromium has since updated their check to be more reliable: https://chromium.googlesource.com/chromium/src.git/+/20f1670fdfc4c0e69a2074adbf87305efa88a29c
I'll work on doing something similar. If anyone can confirm it's a window name issue using MOZ_LOG, that would be helpful.
Comment 13•5 years ago
|
||
Thanks Haik. Unfortunately, I am not able to repro anymore. Arun?
Comment 15•5 years ago
|
||
Setting tracking+ for Fx73, but we're already in RC week so it's not very likely we'll be able to fix this in time.
Reporter | ||
Comment 16•5 years ago
|
||
Do you want to collect from logs from firefox side !?. If you can provide some steps i can collect the logs
Comment 17•5 years ago
|
||
Arun that would be great, since I can't repro anymore! See steps in comment 12.
Updated•5 years ago
|
Assignee | ||
Comment 18•5 years ago
|
||
I'm testing a fix and hope to have it ready for review today or tomorrow.
Assignee | ||
Comment 19•5 years ago
|
||
I have not reproduced this problem, but it seems well known that our implementation of GetScreenCapturePermissionState() is not going to work in some scenarios. See discussion on stackoverflow.com here and Chromium's updated version here.
A test Nightly build with the fix is available at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Oox_1TebRvKk5OTtrgMKXA/runs/0/artifacts/public/build/target.dmg Since the build is not signed by Mozilla, run the following command before mounting the dmg to allow it to be run on Catalina.
$ xattr -c target.dmg
For testing, it might be useful to clear existing Screen Capture permissions with the following command.
$ tccutil reset ScreenCapture
Assignee | ||
Comment 20•5 years ago
|
||
Update the heuristic-based screen recording permission check to be more
reliable but still imperfect.
Add pref "media.macos.screenrecording.oscheck.enabled" (true by default) to
allow bypassing the permission check as a workaround and for testing.
i.e., when the pref is set,
nsIOSPermissionRequest::getScreenCapturePermissionState() always returns
PERMISSION_STATE_AUTHORIZED on macOS.
Assignee | ||
Comment 21•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 22•5 years ago
|
||
To clarify what we think causes this problem:
This is not reproducible for all macOS 10.15 users. We think that the problem is caused by either 1) other applications running with a NULL window name 2) or some type of modal unnamed window being displayed. These could confuse our screen recording permission check. More details below.
Ideally, we can find an example application that triggers this problem and use it to test and verify the fix works.
On macOS, if Firefox detects that the screen recording capability has not be allowed in macOS preferences, an error is reported to the site allowing the site to handle this in a user friendly way. The method used by Firefox to determine if screen recording capability is allowed is somewhat brittle/hacky (and also used by other projects including Chromium) because macOS provides no API. The test makes an API call to get a list of all windows displayed/minimzed/hidden and uses the presence of window names as an indication of screen recording permission.
Comment 23•5 years ago
|
||
Comment 24•5 years ago
|
||
bugherder |
Comment 25•5 years ago
|
||
Please nominate this for Beta approval when you get a chance. I'm not as sure about Release approval for 73.0.1 (though this does graft cleanly there as well).
Assignee | ||
Comment 26•5 years ago
|
||
Comment on attachment 9124848 [details]
Bug 1612006 - getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3 r?spohl!
Beta/Release Uplift Approval Request
- User impact if declined: Some Mac users on macOS 10.15 who attempt to use screen recording (for example, WebRTC screen sharing) on a site will not be able to. The site might return a "NotFoundError" or other similar error. This will happen even after the user has set Firefox to be allowed to record the screen in the macOS System Preferences "Security & Privacy" settings.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: We don't know exactly what scenario causes the problem to occur, but we do want to validate that screen recording continues to work as expected on macOS 10.15. This requires giving Firefox screen recording permission in the macOS "Security & Privacy" settings, but we need to test that Firefox works as expected both before and after the permission has been granted in macOS settings. (The command
tccutil reset ScreenCapture
can be used to reset this panel back to the defaults which can be useful.) See example sites in comment 0 and another example is talky.io. - List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The change code should only be executed on macOS 10.15 and only when the user attempts to use screen recording (or something that exercises the screen recording capability) on a site.
- String changes made/needed:
Assignee | ||
Updated•5 years ago
|
Comment 27•5 years ago
|
||
Comment on attachment 9124848 [details]
Bug 1612006 - getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3 r?spohl!
Approved for 74.0b4 so we can get wider testing.
Comment 28•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 29•5 years ago
|
||
Hi, I've tested this issue on a Mac OsX 10.15.3 and before giving it recording permissions in Security and Privacy from the Os itself I was unable to start Screen Recording as the previously mentioned errors would occur, but after I have granted permissions to Beta 74.0b4, Nightly as well as Release Fx73, I was able to start screen recording without issues.
Since I was unable to reproduce the issue in older builds I feel reluctant to change the flags to Verified for this issue and so arun3528@gmail.com can you please Verify our latest Beta and Nightly builds in order to see if the issue still occurs on your end ? you can find the builds here :
Updated•5 years ago
|
Comment 30•5 years ago
|
||
I'm still able to reproduce this with 74.0.1 and Catalina 10.15.3 with Firefox in full-screen mode (not otherwise). Tried the same here as well https://jan-ivar.github.io/dummy/gdm.html
Description
•