Closed Bug 1648476 Opened 4 years ago Closed 4 years ago

Add an override for Webex calls

Categories

(Web Compatibility :: Interventions, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

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)

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.

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).

Severity: -- → S1
Priority: -- → P2

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:

  1. Join the call in Nightly (no audio)
  2. Open a new tab
  3. Come back to the tab with the call (audio starts working)

(In reply to Ksenia Berezina [:ksenia] from comment #3)

Audio starts working in Nightly with no UA spoof with the following steps:

  1. Join the call in Nightly (no audio)
  2. Open a new tab
  3. 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.

(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.

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.

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