1609101 - WebRTC Screen capture fails with NotFoundError: The object can not be found here.

Status: RESOLVED DUPLICATE of bug 1612006

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

Description

[Hameer Abbasi]

Attachment: Permissions page before launching Firefox.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. Went to https://mozilla.github.io/webrtc-landing/gum_test.html
2. Applied Clicked Screen capture button
3. Approved the security dialog

(I ensured that I have the correct permissions in Settings > Security and Privacy > Privacy > Screen recording)

Actual results:

Got "NotFoundError: The object can not be found here."

Expected results:

The screen capture should have succeeded.

Comment 1

[Paul Adenot (:padenot)]

Jib, one of the weird macOS permission things you know about, do you know what would be the cause of what the reporter see here?

Comment 2

[Hameer Abbasi]

Actually, the point of attaching the image was to verify that permissions weren't the issue. I saw similar tickets being dismissed due to permissions so I decided to attach the image so that this one wouldn't be.

Theoretically, with permissions granted and Firefox restarted (as I did), we should see no behaviour change due to this component of macOS, IIUC.

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Interesting. The NotFoundError does suggest the OS is denying us permission—Firefox does a dummy capture attempt ahead of showing the prompt. It's not impossible we have a bug here, but seems unlikely, since this codepath works for most folks. But I have seen MacOS be flaky here TBH. Have you tried unchecking and re-checking the ☑ Firefox?

I assume you're not starting Firefox from the command line—In that case, you'll need to approve Terminal, not Firefox—or using a different (e.g. Nightly) version than the one shown in the list?

I'm not sure what's going on. I'm not sure there's much we can intuit, unless you're able to reproduce getting into this situation from a working state. Did it used to work?

To get you out of this situation, you can try the following terminal command:

tccutil reset ScreenCapture

This should reset the OS back to the (otherwise unreachable) initial "security prompt" state, where the app needs to ask before it's listed under System Preferences as apps that wish to Screen Record. You may have to quit and restart.

Comment 4

[Hameer Abbasi]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)

Interesting. The NotFoundError does suggest the OS is denying us permission—Firefox does a dummy capture attempt ahead of showing the prompt. It's not impossible we have a bug here, but seems unlikely, since this codepath works for most folks. But I have seen MacOS be flaky here TBH. Have you tried unchecking and re-checking the ☑ Firefox?

Not explicitly, but read on.

I assume you're not starting Firefox from the command line—In that case, you'll need to approve Terminal, not Firefox—or using a different (e.g. Nightly) version than the one shown in the list?

I'm using the Dock.

I'm not sure what's going on. I'm not sure there's much we can intuit, unless you're able to reproduce getting into this situation from a working state. Did it used to work?

It did, yes. I can try going back to an older version, let me do that.

To get you out of this situation, you can try the following terminal command:

tccutil reset ScreenCapture

This should reset the OS back to the (otherwise unreachable) initial "security prompt" state, where the app needs to ask before it's listed under System Preferences as apps that wish to Screen Record. You may have to quit and restart.

I did this, tried the screen capture from Firefox, approved it, restarted Firefox and the "bug" (if we can call it that) still happens.

Comment 5

[Hameer Abbasi]

Okay, I tested fresh profiles of a multitude of old versions. The regression seems to have come about sometime between 69.0 and 70.0.

Comment 6

[Paul Adenot (:padenot)]

jib, do you know if mozregression is useful in a situation like this where information per process is stored in the OS?

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Running the mozregression tool to pinpoint a regressing patch should work, provided you approve ☑ Terminal. WFM.

between 69.0 and 70.0.

That's surprising since NotAllowedError was added in 71 in bug 1588640. Before then, you'd get a picker with only two choices (Firefox, and a dud version of "Entire Desktop").

If you're testing versions before 71, look for the number of choices in the prompt rather than NotAllowedError to tell if you have OS permission or not.

Comment 8

[Alex Chronopoulos [:achronop]]

It might be a real error but the reporter hasn't responded for 4 weeks. I am closing due to that. Feel free to reopen if you have more info.

Comment 9

[Hameer Abbasi]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)

Running the mozregression tool to pinpoint a regressing patch should work, provided you approve ☑ Terminal. WFM.

between 69.0 and 70.0.

That's surprising since NotAllowedError was added in 71 in bug 1588640. Before then, you'd get a picker with only two choices (Firefox, and a dud version of "Entire Desktop").

If you're testing versions before 71, look for the number of choices in the prompt rather than NotAllowedError to tell if you have OS permission or not.

I was getting an empty list in Firefox 70, and before that everything was working (69 and below), with the correct list of windows.

However, the bug seems to have fixed itself in regular use with no explanation from me as to why, so let's keep it closed unless I can find some way to reproduce.

Comment 11

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks, Hameer. We have a second report now and more to go on. Are you perhaps running MacOS 10.15.3, or an earlier version?

Comment 12

[Hameer Abbasi]

It first occurred in 10.15.2, I'm now running 10.15.3. I can't help but notice that my issue was close to when 10.15.2 was released, and bug 1612006 is right on the heels of 10.15.3. Maybe it's some post-installation trigger (on either side) that causes this?

I have to say, I know Firefox itself can access the screen, as I can recall I could see the list of windows fine along with the captured screen when selecting what to share, although initiating the screen capture was what broke it.