Closed Bug 1612006 Opened 5 years ago Closed 5 years ago

getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

72 Branch
Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox-esr68 --- unaffected
firefox72 --- wontfix
firefox73 + wontfix
firefox74 + fixed
firefox75 --- fixed

People

(Reporter: arun3528, Assigned: haik, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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

Component: Untriaged → WebRTC
Product: Firefox → Core

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.

Flags: needinfo?(jib)

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

Arun, please let me know if bug 1606434 comment 1 fixes your problem.

Flags: needinfo?(jib) → needinfo?(arun3528)
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

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

Flags: needinfo?(arun3528)

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.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Flags: needinfo?(arun3528)

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

Flags: needinfo?(arun3528)

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

Severity: normal → critical
Keywords: regression
OS: Unspecified → macOS
Priority: -- → P1
Regressed by: 1588640
Summary: getDisplayMedia failing firefox 72.0.2 → getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3
Has Regression Range: --- → yes
Assignee: nobody → jib

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?

Flags: needinfo?(haftandilian)

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?

Status: REOPENED → UNCONFIRMED
Ever confirmed: false

I guess I did confirm it at one point, so it should be marked NEW.

Status: UNCONFIRMED → NEW
Ever confirmed: true

(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.

Assignee: jib → haftandilian
Flags: needinfo?(haftandilian)

Thanks Haik. Unfortunately, I am not able to repro anymore. Arun?

Flags: needinfo?(arun3528)

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.

Do you want to collect from logs from firefox side !?. If you can provide some steps i can collect the logs

Flags: needinfo?(arun3528)

Arun that would be great, since I can't repro anymore! See steps in comment 12.

Flags: needinfo?(arun3528)

I'm testing a fix and hope to have it ready for review today or tomorrow.

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

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.

Component: WebRTC → WebRTC: Audio/Video

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.

Pushed by haftandilian@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a2e0699b6cb8 getDisplayMedia NotFoundError in firefox after upgrade to MacOS 10.15.3 r=spohl
Status: NEW → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75

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).

Flags: needinfo?(haftandilian)

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:
Flags: needinfo?(haftandilian)
Attachment #9124848 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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.

Attachment #9124848 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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 :

https://www.mozilla.org/ro/firefox/channel/desktop/

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: