Closed Bug 1656252 Opened 4 years ago Closed 3 years ago

[Win] The video gets zoomed in after turning the camera on/off

Categories

(Core :: WebRTC: Audio/Video, defect, P2)

Firefox 81
All
Windows
defect

Tracking

()

RESOLVED DUPLICATE of bug 1637658
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- disabled
firefox79 --- disabled
firefox80 --- disabled
firefox81 - disabled
firefox82 --- disabled
firefox83 + wontfix
firefox84 --- disabled
firefox85 --- disabled
firefox86 --- fixed

People

(Reporter: cgeorgiu, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Affected versions

  • latest Nightly 81.0a1

Affected platforms

  • Windows 10 x64

Steps to reproduce

  1. Start a call between two people via https://meet.google.com/.
  2. Turn off camera on device 1 using the dedicated website button.
  3. Turn on camera on device 1 using the same dedicated website button (grant permissions on the door hanger if FF asks).

Expected result

  • The video is correctly resumed, the video doesn't zoom in.

Actual result

  • The video is not correctly displayed, the video appeared to be zoomed in on device 2.

Regression range

  • The issue is not reproducible on Firefox Release 79.0, I will follow-up with a regression range asap.

Additional notes

  • Please observe the attached screenshot.
  • Note that we were not able to reproduce this on all devices, so please let us know if any other information is needed.
  • The issue is not reproducible on other platforms, nor on Chrome.
  • I would suggest that this issue can be marked with a S3 severity.
Severity: -- → S3
Priority: -- → P3
QA Whiteboard: [qa-regression-triage]
Has Regression Range: --- → no
Has STR: --- → yes

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Priority: P3 → P2

Any luck finding a regression range?

Flags: needinfo?(ciprian.georgiu)

After further investigation on this issue, it seems that the bug only occurs on Nightly builds. We went back with Fx builds down to 78.0a1, where the issue was still reproducible, older builds than this version, didn't display the permission door hanger for the Camera. Given the fact that this somehow triggered the bug, we did not check versions < 78.0a1.

On the latest Beta builds 81.0b7 and Release 80.0.1, we can confirm that the issue is not present. I'll remove the regression range corresponding flags, since this turns out not to be an actual regression.

Let us know if we can help with more info on this.

Flags: needinfo?(ciprian.georgiu)

That makes it sound like it's due to something gated on Nightly-only flag. We should still aim to figure out what that culprit is so this blocks that from shipping.

[Tracking Requested - why for this release]:
it looks like this regression has made it to release now in firefox 83.0 as well (at least i'm seeing a very similar issue with the same symptoms in an internal video conferencing tool based on Blackboard Collaborate which weren't present in 82.0.3 yet). there are also a few reports popping up since last week referencing the same problem with shared screen content: bug 1678971, bug 1677976

just going by the title, bug 1634044 sounds like it may be somewhat related.

Flags: needinfo?(jib)
Flags: needinfo?(dminor)

Something similar has been reported as Bug 1637658 as well.

Flags: needinfo?(dminor)
See Also: → 1637658

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

just going by the title, bug 1634044 sounds like it may be somewhat related.

Bug 1634044 comment 18 landed 2 months ago, whereas this issue was filed 4 months ago, so it cannot be the cause of the regression.

I suppose it's possible it made the problem more prevalent if it's related to downscaling, since downscaling was a bit broken prior to that fix.

Flags: needinfo?(jib)

We're seeing more duplicate reports come in, so this needs prioritization.
It sounds duplicatable, so hopefully someone can figure out what's happening…

looks like the occurrence of this problem on the release channel is coinciding with enabling media.navigator.mediadatadecoder_vpx_enabled (bug 1665329 - thank you jcristau for the hint).
with the pref set to false, the issue is not reproducible - explaining why mozregression doesn't lead to a good result...

Regressed by: 1665329
See Also: → 1646329

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

looks like the occurrence of this problem on the release channel is coinciding with enabling media.navigator.mediadatadecoder_vpx_enabled (bug 1665329 - thank you jcristau for the hint).
with the pref set to false, the issue is not reproducible - explaining why mozregression doesn't lead to a good result...

Thank you for finding this. We are trying to get other to confirm that this fixes the issue. I'm preparing a patch to revert the from bug 1665329.

Depends on: 1680313
Flags: needinfo?(jib)

Fairly certain this is the same bug as bug 1637658.

If someone could test with the fix available here:
https://treeherder.mozilla.org/jobs?repo=try&revision=1e7b5274c048a36c05ae51118e4f9529549bbe26

thanks jya! yes with your try build from comment #12 i don't see the defect with my steps any longer either (while media.navigator.mediadatadecoder_vpx_enabled is set to true).

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

Attachment

General

Created:
Updated:
Size: