User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Any css used on a video element that results as a direct mirror on the x-axis gets ignored.

i.e any of the following:
transform: scaleX(-1);
transform: scale(-1,1);
transform: scale(-1,-1);
transform: rotate(180deg);
etc

This has only started in 96, reverting to 95 makes it work as intended.

Actual results:

Anything that modifies the y-axis will still be affected but the x-axis will immediately revert to initial orientation.

A good example is when using transform: rotate(180deg); if you use 179deg or 181deg they work correctly but 180 will immediately flip the x-axis.

Expected results:

Any modification to the x-axis that results in a mirror should stay as modified.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Using the test case on the <video> documentation page, I'm not able to reproduce the behavior you describe. These all look correct to me and were generated in Nightly 98.0a1 (2022-01-14) on macOS. Here's the original with no transformation

Are you seeing different behavior here, or are you saying the behavior in the above screenshots is not what you expect?

(In reply to Jon Bauman [:jbauman:] from comment #7)

Are you seeing different behavior here, or are you saying the behavior in the above screenshots is not what you expect?

I am seeing different behavior than the screenshots. It happens with 96 but was fixed when I reverted to 95 to test.
(Also your ss for -1,-1 was still -1,1)

This is with troubleshooting mode/all addons disabled, 96.0.1(64-bit):

I included the 179/181 rotates so you can see that it's working in modifying the video but when it hits 180deg it bugs and flips back the x-axis.

I can reproduce the issue in Nightly98.0a1 Windows if HWA off (i.e, the renderer is WebRender (Software))

I also got a report from a user on 97 beta that looks related. The image of the user is flipped 180 degree while it should only be flipped on the x-axis, as usual for video services so a typical mirror image is created. This should have been on HW-WR, but not 100% sure.

Regression window : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=394b3415b476edd81fc8728abb82c25ded4a7d16&tochange=4623948ed21653d413a876dfc10477ceb9c5f5fb

Assuming the issue from comment 18 is indeed the same, then this is not (only) a SW-WR issue.

STR for Linux/Wayland:

• start Firefox with MOZ_ENABLE_WAYLAND=1
• in about:config enable gfx.webrender.compositor.force-enabled
• restart
• visit https://meet.jit.si/, open a new room and enable your camera
• observe the camera image being upside down
• forcing SW-WR via gfx.webrender.software does not have any impact

So this appears to only affect the native compositor backends. Apparently not all though, otherwise we'd have way more reports as this is reproducible for 96/stable up to nightly.

It could be that the issue on Wayland is not the same, just shows similar glitches. Thus opened bug 1750373.

Bug 1750373 turns out not to be a duplicate and had to be fixed in NativeLayerWayland.

The flip is part of the wr::CompositorSurfaceTransform in RenderCompositor::AddSurface. IIUC on Windows with SW-WR, RenderCompositorLayersSWGL is used instead of DCLayerTree (which is used for HW-WR). Both of these implement AddSurface differently, so likely there or somewhere in the Windows layers code the transform matrix is not handled properly.

Looks like this should be trivial to fix: https://searchfox.org/mozilla-central/source/gfx/layers/d3d11/CompositorD3D11.cpp#625

Edit: misread that code, sorry for the noise.

(Also your ss for -1,-1 was still -1,1)

Thanks; fixed that

Thanks for the screenshots, beattie.michaelj! Now, I see the video content itself is buggy despite the player elements being appropriately transformed.

(In reply to Alice0775 White from comment #19)

Regression window : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=394b3415b476edd81fc8728abb82c25ded4a7d16&tochange=4623948ed21653d413a876dfc10477ceb9c5f5fb

Jeff, this is bug 1744117. Any thoughts on this?

Lee, it looks like sw-wr is not handling x-flipped video properly. Is this expected?

SW-WR has never handled X flips. Only Y flips.

(In reply to Lee Salzman [:lsalzman] from comment #28)

SW-WR has never handled X flips. Only Y flips.

Is it easy to add support? With bug 1744117 we depend on it.

https://hg.mozilla.org/mozilla-central/rev/de21b3711d38

Comment on attachment 9259406 [details]
Bug 1750146 - Support SWGL x-flipped composites via linear path. r?jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Bug 1744117 regressed introduced this regression in the 96 release. Software WebRender on any platforms may cause content to be incorrectly flipped around (i.e. video conferencing apps such as jitsi that needs to flip camera feeds).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fairly simple code change that just changes the orientation a surface is composited with on request.
• String changes made/needed:

Comment on attachment 9259406 [details]
Bug 1750146 - Support SWGL x-flipped composites via linear path. r?jrmuizel

Approved for 97.0b6. Thanks for including tests with this.

https://hg.mozilla.org/releases/mozilla-beta/rev/1292499fe0b5