Closed Bug 1587421 Opened 2 months ago Closed 2 months ago

OpenH264 Plugin stops working after Update to Catalina (Mac OS 10.15)

Categories

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

69 Branch
Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox69 - wontfix
firefox70 + fixed
firefox71 --- fixed

People

(Reporter: martin-ramm, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached image mac-ff-open264.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

  • Firefox is installed on a Mac device running Mac OS 10.14
  • Confirm that the OpenH264 Video Codec V 1.8.1 plugin is installed
  • Update the OS to 10.15
  • Go to a WebRTC meeting, and try to share your webcam or screen

Actual results:

  • I can see the stream locally.
  • The stream is not sent, i.e. the counterpart in the meeting won't receive the stream
  • The attached window opened. It reads, translated from German:
    "libgmpopenh264.dylib" can't be opened, because the developer can't be verified.
    macOS cannot verify that this App is malware free.
    Firefox downloaded this file on the 3rd June 2019.

Expected results:

  • No error message should be displayed when sending a stream
  • My counterpart in the meeting should receive the stream

Workaround that worked:

  • Close FF
  • Remove the 1.8.1 folder, where the extension is located
  • Open FF again and force it to re-download the extension.

The User Agent of the effected FF system is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:69.0) Gecko/20100101 Firefox/69.0

Component: Untriaged → Audio/Video: GMP
OS: Unspecified → macOS
Product: Firefox → Core

Martin - thanks for filing - I wondered what you are using for your WebRTC meeting - this will help us try to reproduce the issue. Thanks.

could this basically be bug 1558924 for the cisco plugin?

Flags: needinfo?(haftandilian)
Flags: needinfo?(haftandilian)
See Also: → 1566523
Flags: needinfo?(haftandilian)

I can repro with 71 on Catalina.
Yes this only affects WebRTC calls which require H264.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

Based on the comment 0 it sounds like this is due to us not having cleared the quarantine attribute. However, if we redownload the plugin, then it works (i.e. the attribute is cleared). My suspicion is that if we downloaded the plugin in an older version of Firefox that was not clearing the attribute then we'll get into this situation.

Suggested mitigation: we ship a dummy update to Firefox versions that have the clear attribute code. The update points to the same plugin files on the remote server, but that will force another download which should clear the quarantine attribute.

i assume balrog would be able to gate such a gmp-update to versions containing the patch from bug 1566523 (firefox 69.0+, 60.9.0esr and 68.1.0esr+ on macos)?

(In reply to [:philipp] from comment #6)

i assume balrog would be able to gate such a gmp-update to versions containing the patch from bug 1566523 (firefox 69.0+, 60.9.0esr and 68.1.0esr+ on macos)?

I believe so.

I can also confirm that starting with a fresh profile in 69 and 70, which results in downloading OpenH264 freshly from the servers, works just fine. So I think that supports the theory that re-downloading the existing 1.8.1 release should fix this issue.

Depends on: 1587533
Flags: needinfo?(haftandilian)

(In reply to Bryce Seager van Dyk (:bryce) from comment #5)

Based on the comment 0 it sounds like this is due to us not having cleared the quarantine attribute. However, if we redownload the plugin, then it works (i.e. the attribute is cleared). My suspicion is that if we downloaded the plugin in an older version of Firefox that was not clearing the attribute then we'll get into this situation.

Suggested mitigation: we ship a dummy update to Firefox versions that have the clear attribute code. The update points to the same plugin files on the remote server, but that will force another download which should clear the quarantine attribute.

Clearing my needinfo. I agree with Bryce's evaluation above and testing shows that's what's happening. Bryce is addressing this on bug 1587533.

That bug led to another which led to bug 1587537. Looks like release engineering is handling that.

I believe this should be mitigated in 70+ and ESR68.3+ by changes to our balrog rules. There are some changes to the fallback downloader that I'm still looking at having uplifted, but this should be broadly addressed.

Resolving. Please reopen and/or let me know if I've overlooked anything we need do further.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.