web.ciscospark.com sometimes displays a zoomed-in upper-left corner of the video feed

VERIFIED FIXED in Firefox 65



2 months ago
16 days ago


(Reporter: ccomorasu, Assigned: padenot)


({cisco-spark, regression})

cisco-spark, regression

Firefox Tracking Flags

(relnote-firefox 65+, firefox-esr60 unaffected, firefox64 unaffected, firefox65+ verified, firefox66+ verified, firefox67+ verified)



(1 obsolete attachment)


  • Must have two accounts on the http://web.ciscospark.com/.
  • This issue has occured on Ubuntu 16.04 LTS.
  • The affected OS's have the following GPU: Intel(R) HD Graphics 5500

Affected versions

  • Fx 65.0b10
  • Fx 66.0a1

Affected platforms

  • Fx 65.0b10 and Fx 66.0a1(web app) Ubuntu 16.04 LTS (affected) and Fx 64.0.2 macOS 10.14
  • Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and native app Windows 10 x64.
  • Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and native app macOS 10.14 (it occurred for a few seconds).
  • Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and web app macOS 10.14 (it occurred for a few seconds).

Steps to reproduce

  1. Launch Firefox.
  2. Go to http://web.ciscospark.com/ and log in.
  3. Initiate a call.

Expected result

  • The call has no audio/video issues.

Actual result

  • As soon as the call is initiated, the native app notices a flicker in the video then the video displayed is a zoom in in the upper-left corner.

Regression range

  • Will investigate as soon as possible.

Additional notes

Thanks Cristian, does it work in 64? If not, what makes you suspect a browser bug?

You mention "native app", does this only happen on calls between firefox and a native app? Is the abnormal video observed on the Firefox side or the native app side? Does it work better using Chrome?

A regression range would help of course.

Flags: needinfo?(cristian.comorasu)

We managed to reproduce it again using:

  • Ubutu 18.04 LTS - Fx 65.0b11 (affected) and native app Windows 10 x64

However we did not reproduce it on Fx 64.0.2, nor using Chrome.
We will return with the regression range as soon as possible (it does not reproduce every time).

status-firefox64: --- → unaffected
Has Regression Range: --- → no
Keywords: regressionwindow-wanted
Has Regression Range: no → yes
Has STR: --- → yes
Flags: needinfo?(cristian.comorasu)
Keywords: regressionwindow-wanted

Thanks Cristan! That seems to point to bug 1505284.

Blocks: 1505284
Flags: needinfo?(jyavenard)
Keywords: regression
status-firefox67: --- → affected
status-firefox-esr60: --- → unaffected

Paul can you look at this since you reviewed bug 1505284 and we haven't had a response yet from jya?

Flags: needinfo?(padenot)

Comment 6

2 months ago

In this range, we have two things: preffing on MediaDataDecoder for vp8 and vp9, and also for h264. This is a change in API and also potentially in decoding backend (this depends on the CPU, GPU, OS and OS version). The vp8 and vp9 changes are nightly only, so I think this is h264, because we can repro on 65, that was being built as a beta.

If we feel that not regressing this is important (it's too late considering we've regressed 65 already and we've shipped that), let's pref off and try to repro without the pref to get a solution as fast as possible.

The pref to flip is:


It must be set to false to try to repro. If we can't repro with this set to false, then we have a culprit and we can discuss about shipping this pref flip.

Now, about the bug. We're displaying the top-left quarter of the video received, and we think the problem is on the decoding side. This means that some coordinates or sizes are off. The prose isn't too precise, but a flicker can be thought of as a resolution change, especially if it happens some seconds after the beginning of the call.

It can be that after starting the call for a bit, the link is deemed good enough to start using higher-resolution video, that is four times bigger, and something is not updated: either the dimension of a texture: we only composite one quarter, the dimensions reported in js (and the web app crops it), that kind of thing. If this is the case, we should be able to reproduce a bit more easily by using network link conditioning techniques (tc or whatever).

Cristian, if possible, I'd like to have:

  • Precise instruction on how to reproduce this: for example, I don't know what the Native App is (I can't find a way to download it on the web). I have all OSes on multiple machines here, so I hope I'll be able to reproduce.
  • Infos on whether this pref flip fixes this regression

I seem to recall that jya told me something about resolution changes on some codec that wasn't supported, but my memory on the topic is fuzzy, I'll try to ping him.

Flags: needinfo?(padenot) → needinfo?(cristian.comorasu)

Hello Paul,

I used a Windows 7 x64 (about:support can be found here: https://pastebin.com/cNwxs2Ex ) and logged in here: http://web.ciscospark.com/. I initiated a call with a Widows 10 x64 having this app: https://www.webex.com/downloads.html (Cisco Webex Teams). After a few seconds the video feed on the Windows 7 x64 was zoomed in.

Flipping media.navigator.mediadatadecoder_h264_enabled pref code fixes the issue.

Best regards,
Cristian Comorasu.

Flags: needinfo?(cristian.comorasu)

Comment 9

a month ago

Cool. So in release and beta and such, we can ship a pref flip. jya is having a look at the real issue.

Flags: needinfo?(padenot)
Blocks: 1519860

Now the question is should we uplift the fix in bug 1525230 which is the proper fix
or uplift this one which only turns off the pref.

The advantage of bug 1525230 fix is that it allows us to not use OpenH264 which currently gives issue when another peer is using Safari.

Flags: needinfo?(jyavenard)
See Also: → bug 1525230
No longer blocks: 1519860
tracking-firefox65: --- → +
tracking-firefox66: --- → +
tracking-firefox67: --- → +

Comment on attachment 9041835 [details]
Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?jya

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1505284

User impact if declined

People will see cropped face during a video call

Is this code covered by automated tests?


Has the fix been verified in Nightly?


Needs manual test from QE?


If yes, steps to reproduce

Steps are provided in bug 1521530

List of other uplifts needed


Risk to taking this patch


Why is the change risky/not risky? (and alternatives if risky)

Pref off code that made it to 65, reverting back to Firefox 64 code path

String changes made/needed

Attachment #9041835 - Flags: approval-mozilla-release?
Priority: -- → P1
Assignee: nobody → padenot

This should be fixed via bug 1525230 for 66/67.

Last Resolved: a month ago
status-firefox66: affected → fixed
status-firefox67: affected → fixed
Flags: qe-verify+
Flags: needinfo?(cristian.comorasu)
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Comment on attachment 9041835 [details]
Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?jya

[Triage Comment]
Reverts us back to Fx64 behavior for Fx65, approved for 65.0.1.

Attachment #9041835 - Flags: approval-mozilla-release? → approval-mozilla-release+

I could still reproduce this issue using Fx 66.0b6, I will return when Fx 66.0b7 is live.

Flags: needinfo?(cristian.comorasu)
Flags: needinfo?(cristian.comorasu)
relnote-firefox: --- → 65+

Comment 16

a month ago
status-firefox65: affected → fixed
Whiteboard: [qa-triaged]

I can confirm this issue is fixed, I verified using Fx 65.0.1, Fx 66.0b7 and Fx 67.0a1 on the same environment as in the description.

status-firefox65: fixed → verified
status-firefox66: fixed → verified
status-firefox67: fixed → verified
Flags: qe-verify+
Flags: needinfo?(cristian.comorasu)
Attachment #9041835 - Attachment is obsolete: true
QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]
You need to log in before you can comment on or make changes to this bug.