I think this is a sandboxing issue. I'm working on confirming that and will update the bug after I do some more testing.

While debugging why AV1 decoding is not working on 10.15, I found that the RDD process is crashing here in a SetProcessName() stack.

The message "BUG IN LIBDISPATCH: Unable to get the unique pid (size)" indicates the proc_pidinfo() syscall is failing and this is likely to be due to sandbox restrictions. This is one of the problems we hit with Widevine decoding on 10.15 on bug 1558924 and I didn't realize the SetProcessName() crash was similar.

This is looking good on nightly so far. The main signature in this bug has not been seen since the fix landed, and I am not seeing any of the single installation Mac crashes in my nightly crash triage in the last few days :)

Why is the change risky/not risky? (and alternatives if risky): The fix is small, limited to macOS, and just adds a new process sandbox rule needed on 10.15 that is unlikely to cause problems with earlier macOS versions.

This is looking good on nightly so far. The main signature in this bug has not been seen since the fix landed, and I am not seeing any of the single installation Mac crashes in my nightly crash triage in the last few days :)

I tested this on iMac and MacBook Pro OS X 10.15 Beta (19A501i) with the latest FF Nightly 70.0a1(2019-07-16) and I can't reproduce any crash but there is a problem, the video doesn't start and there is an error displayed, please see the attached document.
Haik, can you please take a look at this? Thanks

I tested this on iMac and MacBook Pro OS X 10.15 Beta (19A501i) with the latest FF Nightly 70.0a1(2019-07-16) and I can't reproduce any crash but there is a problem, the video doesn't start and there is an error displayed, please see the attached document.
Haik, can you please take a look at this? Thanks

That's the error you should see without the fix. The RDD process is crashing, but it doesn't cause a crashed tab page like a content process crash would.

Once you have the fix, you should not see that error and instead should see the video playing.

Per discussion with jcristau, we're uplifting this to 68.0.1esr also to maintain parity with the non-ESR 68.0.1 release and hopefully avoid some confusion.

Thanks for catching that. ESR 68 should have been in my uplift request. This fix is needed in ESR 68 because the bug affects all Firefox versions with the RDD process enabled (65+) run on macOS 10.15 and we'll be supporting ESR 68 on 10.15.

But bug 1560368 is only on 70 which wouldn't explain the issue on Beta.

I'll file a new bug post details there.

Haik, I'm not exactly sure what the question here is for me. What I've gathered from reading through the 2 bugs (this one and Bug 1566540) is that there is possibly a sandbox issue related only to RDD and macOS 10.15? Please let me know what I can do to help. I don't have a 10.15 machine here, but if necessary I can probably track down a spare drive to install the 10.15 beta on.

Haik, I'm not exactly sure what the question here is for me. What I've gathered from reading through the 2 bugs (this one and Bug 1566540) is that there is possibly a sandbox issue related only to RDD and macOS 10.15? Please let me know what I can do to help. I don't have a 10.15 machine here, but if necessary I can probably track down a spare drive to install the 10.15 beta on.

Sorry for not being clear. Originally, due to the mozregression result, the crash looked like a possible regression caused by bug 1560368. Now, after looking at the crash some more, I think it could be a new 10.15 sandboxing issue exposed by the RDD changes in bug 1560368. I'll work on bug 1566540 assuming it is a sandboxing issue.

Hi Ryan, we tested this issue on Mac OS X 10.15 Beta 5 but we are blocked by bug 1570451, however, we manage to test this issue using an older OS 10.15 Beta version and with the Latest Nightly 70.0a1 (2019-08-15) and Beta 69.0b14 the issue is no longer reproducible.
So to answer your question, yes we can call this verified for 69/70.