Add an override for Webex calls
Categories
(Web Compatibility :: Interventions, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: ksenia, Unassigned)
References
()
Details
We need to investigate if it's possible to fix the issue with no audio on Webex calls by adding a UA override.
We could add the override to *.webex.com domains (example domains: meetingsamer12.webex.com, tdsb.webex.com)
|
||
Comment 1•4 years ago
•
|
||
Thanks, Ksenia! I think we hold off on writing an override patch until Webex confirms the problem. Perhaps they can provide a list of affected domains we should override.
In bug 1643204 comment 0, dbaron originally reported Webex audio problems with W3C meeting held on Webex. The domain was mit.webex.com.
|
||
Comment 2•4 years ago
|
||
I think we hold off on writing an override patch until Webex confirms the problem.
SGTM -- ideally someone can ping this bug if and when we get that signal (since I don't believe we're looped into those conversations).
|
Reporter | |
Comment 3•4 years ago
•
|
||
Some findings if we end up doing the override:
As Matt mentioned in comment 9, audio works with the following spoofed UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4 Supplemental Update) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15 and not working with Chrome UA.
Audio starts working in Nightly with no UA spoof with the following steps:
- Join the call in Nightly (no audio)
- Open a new tab
- Come back to the tab with the call (audio starts working)
|
||
Comment 4•4 years ago
|
||
(In reply to Ksenia Berezina [:ksenia] from comment #3)
Audio starts working in Nightly with no UA spoof with the following steps:
- Join the call in Nightly (no audio)
- Open a new tab
- Come back to the tab with the call (audio starts working)
It appears that they're relying on the "pageshow" event (which we stopped firing for aborted loads). Switching tabs would cause a new "pageshow" event to be fired, which is likely why this fixes the issue.
|
|
||
Comment 5•4 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #2)
I think we hold off on writing an override patch until Webex confirms the problem.
SGTM -- ideally someone can ping this bug if and when we get that signal (since I don't believe we're looped into those conversations).
I'm working with stpeter to contact Webex. I will follow up in this bug as I learn more.
|
|
||
Comment 6•4 years ago
|
||
Resolving as WONTFIX because Matt Woodrow will land his backout patch (in bug 1643204) in Fx79 Beta. We'll leave the code (and regression) in Fx80 Nightly. Spoofing Firefox as Safari could have more serious side effects.
stpeter contacted Webex developers and they're investigating. If Webex hasn't deployed a server fix when Fx80 rides from Nightly to Beta, we might just publish a SUMO article describing the Webex workaround (that Ksenia reported in comment 3) instead of backing out the code from Beta again.
Description
•