Closed
Bug 1494179
Opened 6 years ago
Closed 5 years ago
Firefox crashes because openh264 plug-in is disabled when do video call in Webex web app
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: ruil2, Unassigned)
References
Details
Crash Data
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15
Steps to reproduce:
Firefox crashes when customer try to open video / share content through Webex meetings web app. the root cause is the OpenH264 plugin has been disabled for some reason.
Actual results:
the Webex app will crash when openh264 plugin is disabled for some reasons
Expected results:
Webex app can work well by query the status of openh264 plugin. when the openh264 plug-in is disabled, it can enable the plugin or pop-up a warning.
Updated•6 years ago
|
Component: Untriaged → Audio/Video: GMP
Product: Firefox → Core
Comment 1•6 years ago
|
||
Lets start with Firefox should not crash in this scenario. If Firefox really crashes could you please either let us know the steps how to reproduce this, or open about:crashes in Firefox after a crash a provide us with the link to a crash report.
OpenH264 is an extension to Firefox and web sites never get control over enabling or disabling extensions or add-ons. That would introduce a pretty big security problem.
An initial installation of Firefox will not have the OpenH264 extension available yet, because the extension only gets downloaded after some time of inactivity. This is very common problem in test automation.
And yes a user can choose to manually disable the OpenH264 extension at any given time.
For both of these cases, the extension not being available yet or the extension being disabled by the user, the web app can find out if the H264 codec is available by calling createOffer() and search in the SDP for H264.
HI Nils:
the below are crash links.
1) Installed Ubuntu 64 with Firefox ESR 60-64 bit---> Unable to share content; browser will crash
Crash report: https://crash-stats.mozilla.com/report/index/9c89957c-4e3d-43d8-bb6e-fa5f10180913
2) Installed CentOs 64bit with Firefox ESR 60-64bit---> Unable to share content; browser will crash
Crash report: https://crash-stats.mozilla.com/report/index/1c1bb56e-beec-46e3-96d4-5d1b80180913
3) Installed Windows 7-64bit with Firefox ESR 60-64bit---> Unable to share content; browser will crash
Crash report: https://crash-stats.mozilla.com/report/index/23519228-2deb-4f62-8e95-d80bf0180913
Comment 3•6 years ago
|
||
(In reply to karina from comment #2)
> 3) Installed Windows 7-64bit with Firefox ESR 60-64bit---> Unable to share
> content; browser will crash
>
> Crash report:
> https://crash-stats.mozilla.com/report/index/23519228-2deb-4f62-8e95-
> d80bf0180913
This one crashes in the Transceiver impl. Looks like this happens when you disable the OpenH264 plugin and then use a service which only works with H264 like WebEx or Spark (WebEx Teams).
The crash report also points to bug 1465617, which is still open, because we don't have STR.
Byron could you please have a look?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(docfaraday)
Priority: -- → P2
See Also: → 1465617
Updated•6 years ago
|
Component: Audio/Video: GMP → WebRTC: Signaling
Updated•6 years ago
|
Crash Signature: [@ mozilla::TransceiverImpl::UpdateVideoConduit]
Comment 4•6 years ago
|
||
Pretty sure this is bug 1465617. Can you reproduce this on nightly?
Flags: needinfo?(docfaraday) → needinfo?(ruil2)
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ruil2)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•