2030296 - [Win10] Netflix videos not rendered on HDR enabled display

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: about support.txt

Found in

• Firefox 151.0a1 (2026-04-08)

Affected versions

• Firefox 151.0a1 (2026-04-08)

Unaffected versions

• Firefox 150.0b4

Tested platforms

• Affected platforms: Windows 10

Preconditions

• HDR capable display and HDR enabled in Windows settings -> Nightly opened on the HDR monitor.

Steps to reproduce

1. Load and play a HDR capable movie/series on Netflix -> Example

Expected result

• The video uses HDR for video rendering and no issues occur

Actual result

• The video gitches and is unviewable

Additional Notes

• The issue can be seen in the following attachment. Filmed the difference from SDR display (integrated display of laptop) to HDR (the external display).
• This is repducible by opening the video directly on the HDR display or by moving the window from an SDR one to HDR.
• The videos work correctly on the SDR display (video directly opened on SDR display or moved from HDR to SDR it will revert and display correctly).
• Youtube videos are correctly rendered with HDR but suffer from performance issues from Bug 2029122.
• The about support infos are attached here as well.

Comment 1

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Looked for a regression and found that it was introduced between 31-03 and 01-04. Here's the pushlog. The cause is most probably Bug 2012850.

Comment 2

[Ashley Hale [:ahale]]

Speculating that a DRM video code path is not passing the correct transfer function, causing this regression...

Comment 3

[Jim Mathies [:jimm]]

I'm not sure I consider this a blocker.

Catalin, I'm curious if you open Firefox on the HDR display, does it look correct? I think you're saying it does not, but I wasn't sure.

Comment 4

[Jim Mathies [:jimm]]

From the test device about:support:
GPU #1
Active: Yes
Description: Intel(R) UHD Graphics 620
Vendor ID: 0x8086
Device ID: 0x5917
Driver Version: 31.0.101.2140
Driver Date: 11-5-2025
Drivers: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
Subsys ID: 397317aa

Display0: 1920x1080@60Hz scales:1.000000|1.000000 SDR
Display1: 3840x2160@60Hz scales:1.000000|1.500000 HDR

Comment 5

[Alastor Wu [:alwu]]

Can you press CTRL+SHIFT+ALT+D on Netflix to see what key system is using? If it's PlayReady, then please set the pref media.eme.playready.enabled=false and restart browser to see if same issue also happens on Widevine. Thanks!

Comment 6

[Alastor Wu [:alwu]]

(In reply to Ashley Hale [:ahale] from comment #2)

Speculating that a DRM video code path is not passing the correct transfer function, causing this regression...

That’s likely the case. I’ll prepare a patch to address it. However, my setup (not HDR-capable) can’t reproduce the issue, it also doesn’t provide HDR content. so I can’t verify the fix. I will ask Catalin to test my own build later.

Comment 7

[Ashley Hale [:ahale]]

We should address Bug 2028843 which will make it possible to test without an HDR display attached.

Comment 8

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Hey Jim, if I open the video directly on the HDR display it will not render (mentioned this scenario on the second point from Additional notes). On the attached video I just moved the video from the SDR one to HDR to see that even in that scenario it will still not render. But as soon as I move the video from HDR to the internal display it will be rendered as expected.

Comment 9

[Alastor Wu [:alwu]]

Could you help me confirm the question in the comment 5? In addition, could you try this build to see if it helps? Thanks!

Comment 10

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Fix MF_MT_TRANSFER_FUNCTION mapping to correctly handle PQ and HLG HDR content

Pass the correct transfer function when setting up WMF Media Engine media
types so that HDR video color is displayed correctly.

Comment 11

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: netflix data.PNG

Sure thing, so I've looked on Firefox Nightly 151.0a1 (2026-04-14) and the same behavior is there, I'll attach a photo with the data from Netflix. Seems it is not using PlayReady but SW decode instead and I've gone anyway and switched media.eme.playready.enabled to false to be 100% sure and it still happens nonetheless.

Also tried the build you linked in Comment 5 and it is till affected by the issue, same infos are provided by CTRL+SHIFT+ALT+D.

Let me know how can I help further!

Comment 12

[Alastor Wu [:alwu]]

Will this issue happen on PlayReady? Or all HDR videos you see are Widevine? Thanks!

Comment 13

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Seems to be Widevine. I don't think this system supports PlayReady (unless there is some way to force it?). Unfortunately the system that I have and is 100% capable by default and use PlayReady has only Windows 11 and there we haven't encountered this exact issue.

Comment 14

[Jim Mathies [:jimm]]

I can test here as well, win11+Intel.

Comment 15

[Alastor Wu [:alwu]]

Ok, then let me file another new bug for my patch, which can deal with the wrong color for PlayReady, and keep investigate this issue. Could you help capture a media profile by following this instruction? In addition, can you reproduce this issue on Windows 11? Or it's Windows 10 only? Thanks!

Comment 16

[Phabricator Automation]

Comment on attachment 9569987 [details]
Bug 2030296 - Fix MF_MT_TRANSFER_FUNCTION mapping to correctly handle PQ and HLG HDR content

Revision D294303 was moved to bug 2032534. Setting attachment 9569987 [details] to obsolete.

Comment 17

[Jim Mathies [:jimm]]

win11 + nightly w/media logging - https://share.firefox.dev/4vAVtHa

video - https://www.netflix.com/watch/81702189?trackId=14170286&tctx=1%2C0%2C54aaa5fd-bedb-4b6b-b2d4-22afd38da951-283091028%2CNES_6528B406331CF7618807454792F778-994911DC4F528C-728D21EA34_p_1775228588820%2CNES_6528B406331CF7618807454792F778_p_1775228588820%2C%2C%2C%2C%2CVideo%3A81485923%2CminiDpPlayButton

(same as the example in original post)

Appears as correct appearing SD content. Netflix reports no HDR support for the device, which is inaccurate.

Comment 18

[Jim Mathies [:jimm]]

Build -
Name Firefox
Version 151.0a1
Build ID 20260416093720

Netflix debug info on my laptop -

Version: 6.0056.553.911
Esn: NFCDFF-02-MY27V7Q4GXF86EN504GW1P2MKWXQTJ
PBCID: 6.HiZw6yJg2UrRCdUi8_Mlrf4GL3tdWGvPe2pGjv7Ol4s
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0

MovieId: 81702189
PackageId: 2339037
Xid: 177636218746350820 (177636218746350820)
Position: 77.536
Duration: 3050.172
PlayerDuration: 3050.172
Volume: 100%
Segment: 81702189:main
Segment Position: 77.536

Player state: Normal
Buffering state: Normal
Rendering state: Playing

Playing bitrate (a/v): 128 / 1034 (1920x1080)
Playing/Buffering vmaf: 94/94
Buffering bitrate (a/v): 128 / 1034
Buffer size in Bytes (a/v): 0 / 0
Buffer size in Bytes: 0
Buffer size in Seconds (a/v): 230.705 / 232.356
Downloadables (a/v): 1481082615 / 1537195826
Current CDN (a/v/t): c176.tpa001.ix.nflxvideo.net, Id: 81966 / c167.tpa001.ix.nflxvideo.net, Id: 82008 / ?

Audio Track: en, Id: A:2:1;2;en;1;0;, Channels: 2.0, Codec: audio/mp4;codecs=mp4a.40.5 (he-aac)
Audio Tags: SpeakerSpatialAudio
Video Track: Codec: video/mp4;codecs=av01.0.04M.08 (av1, prk)
Video Tags: EVEAV1,FGS,MCCLEAREN_AV1,identPOI
Timed Text Track: none

Framerate: 23.976
Current Dropped Frames:
Total Frames: 233
Total Dropped Frames: 0
Total Corrupted Frames: undefined
Main Thread stall/sec: DISABLED
KeySystem: com.widevine.alpha.SW_SECURE_DECODE
KeyStatus: AAAAAAlQF9gAAAAAAAAAAA==,AAAAAAlQF9sAAAAAAAAAAA==, 540,1080, usable,usable
VideoDiag: readyState=4,currentTime=77.661145,pbRate=1,videoBuffered=43.835,videoRanges=64.898166-108.733625,audioBuffered=47.232,audioRanges=64.896-112.128,duration=3050.1721
HDR support: false (media-capabilities)

Throughput: 73501 kbps

Comment 19

[Jim Mathies [:jimm]]

Attachment: test results for widevine

Comment 20

[Jim Mathies [:jimm]]

https://share.firefox.dev/4cx47ho

media capabilities logging

Comment 21

[Jim Mathies [:jimm]]

Chrome netflix debug -
Version: 6.0056.553.911
Esn: NFCDCH-02-MXE02RUUX3A9M00NYTJ80N3U3GPFRE
PBCID: 6.6xkutOJC0doIk6wshLYPkmcT_NvFPXy3iCd9q0I80sM
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

MovieId: 81702189
PackageId: 2339037
Xid: 177636453069371100 (177636453069371100)
Position: 284.522
Duration: 3050.172
PlayerDuration: 3050.172
Volume: 100%
Segment: 81702189:main
Segment Position: 284.522

Player state: Normal
Buffering state: Normal
Rendering state: Paused

Playing bitrate (a/v): 192 / 11161 (3840x2160)
Playing/Buffering vmaf: 101/101
Buffering bitrate (a/v): 192 / 17530
Buffer size in Bytes (a/v): 0 / 0
Buffer size in Bytes: 0
Buffer size in Seconds (a/v): 133.014 / 103.031
Downloadables (a/v): 1530894088 / 1713020645
Current CDN (a/v/t): c159.tpa001.ix.nflxvideo.net, Id: 82009 / c160.tpa001.ix.nflxvideo.net, Id: 81967 / ?

Audio Track: en, Id: A:2:1;2;en;1;0;, Channels: 2.0, Codec: audio/mp4;codecs=mp4a.40.42 (xhe-aac)
Audio Tags: SpeakerSpatialAudio
Video Track: Codec: video/mp4;codecs=hev1.1.6.L93.B0 (hevc, hdr, prk)
Video Tags: CE4_HDR10_DO_v1,MCCLEAREN_HDR10,NOP,identPOI
Timed Text Track: none

Framerate: 23.976
Current Dropped Frames:
Total Frames: 480
Total Dropped Frames: 0
Total Corrupted Frames: 0
Main Thread stall/sec: DISABLED
KeySystem: com.microsoft.playready.recommendation.3000
KeyStatus: AAAAAAlQF+oAAAAAAAAAAA==,AAAAAAlQF+sAAAAAAAAAAA==,AAAAAAlQF+wAAAAAAAAAAA==, 540,1080,2160, usable,usable,usable
VideoDiag: readyState=4,currentTime=284.521555,pbRate=1,videoBuffered=50.717,videoRanges=268.601666-319.318999,audioBuffered=50.731,audioRanges=268.586666-319.317333,duration=3050.1721
HDR support: true (media-capabilities)Version: 6.0056.553.911
Esn: NFCDCH-02-MXE02RUUX3A9M00NYTJ80N3U3GPFRE
PBCID: 6.6xkutOJC0doIk6wshLYPkmcT_NvFPXy3iCd9q0I80sM
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

MovieId: 81702189
PackageId: 2339037
Xid: 177636453069371100 (177636453069371100)
Position: 284.522
Duration: 3050.172
PlayerDuration: 3050.172
Volume: 100%
Segment: 81702189:main
Segment Position: 284.522

Player state: Normal
Buffering state: Normal
Rendering state: Paused

Playing bitrate (a/v): 192 / 11161 (3840x2160)
Playing/Buffering vmaf: 101/101
Buffering bitrate (a/v): 192 / 17530
Buffer size in Bytes (a/v): 0 / 0
Buffer size in Bytes: 0
Buffer size in Seconds (a/v): 133.014 / 103.031
Downloadables (a/v): 1530894088 / 1713020645
Current CDN (a/v/t): c159.tpa001.ix.nflxvideo.net, Id: 82009 / c160.tpa001.ix.nflxvideo.net, Id: 81967 / ?

Audio Track: en, Id: A:2:1;2;en;1;0;, Channels: 2.0, Codec: audio/mp4;codecs=mp4a.40.42 (xhe-aac)
Audio Tags: SpeakerSpatialAudio
Video Track: Codec: video/mp4;codecs=hev1.1.6.L93.B0 (hevc, hdr, prk)
Video Tags: CE4_HDR10_DO_v1,MCCLEAREN_HDR10,NOP,identPOI
Timed Text Track: none

Framerate: 23.976
Current Dropped Frames:
Total Frames: 480
Total Dropped Frames: 0
Total Corrupted Frames: 0
Main Thread stall/sec: DISABLED
KeySystem: com.microsoft.playready.recommendation.3000
KeyStatus: AAAAAAlQF+oAAAAAAAAAAA==,AAAAAAlQF+sAAAAAAAAAAA==,AAAAAAlQF+wAAAAAAAAAAA==, 540,1080,2160, usable,usable,usable
VideoDiag: readyState=4,currentTime=284.521555,pbRate=1,videoBuffered=50.717,videoRanges=268.601666-319.318999,audioBuffered=50.731,audioRanges=268.586666-319.317333,duration=3050.1721
HDR support: true (media-capabilities)

Comment 22

[Alastor Wu [:alwu]]

The comment 17 to comment 21 are all related with another issue, I've filed bug 2030296 for that.

Comment 23

[Alastor Wu [:alwu]]

The issue might be caused by not setting the transfer function for MP4. I’ve filed bug 2032615 to update mp4parser once the upstream PR is accepted. After that, I’ll apply a follow-up patch to wire everything together.

Comment 24

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 2: Read NCLX colr box in MP4VideoInfo::Update().

When parsing fMP4 video tracks, the colr box carrying CICP colour primaries,
transfer characteristics, and matrix coefficients was never read. This caused
HDR10 content to fall back to BT.709 in downstream decoders, rendering
near-black on HDR displays.

Populate the colour space fields from the NCLX colr box data when present.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2012850

Comment 26

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Here's a captured media profile from my win 10 system, hope it helps.

Comment 27

[Ashley Hale [:ahale]]

Looked at the profile briefly, seeing a lot of this line: PlatformDecoderModule — [Debug] PlatformDecoderModule: MFTDecoder::Create, created decoder, input=MFVideoFormat_NV12, output=MFVideoFormat_ARGB32

Is this video not HDR? it seems like it should be picking MFVideoFormat_P010 if it is HDR...

Comment 28

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 1: Update mp4parse to 952f5173.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c1c75b1a145a
https://hg.mozilla.org/integration/autoland/rev/29c78c2f832b
Part 1: Update mp4parse to 952f5173. r=aosmond
https://github.com/mozilla-firefox/firefox/commit/297cc5094ef0
https://hg.mozilla.org/integration/autoland/rev/abdde6f33992
Part 2: Read NCLX colr box in MP4VideoInfo::Update(). r=kinetik

Comment 30

[rperta]

https://hg.mozilla.org/mozilla-central/rev/29c78c2f832b
https://hg.mozilla.org/mozilla-central/rev/abdde6f33992

Comment 31

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 1: Update mp4parse to 952f5173.

Original Revision: https://phabricator.services.mozilla.com/D295343

Comment 32

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: HDR Netflix video corruption
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: See comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: It’s about supporting parsing HDR-related information for MP4, which we already support for WebM. So it doesn’t introduce a new feature or change existing behavior.
• String changes made/needed?: No
• Is Android affected?: unknown

Comment 33

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 2: Read NCLX colr box in MP4VideoInfo::Update().

When parsing fMP4 video tracks, the colr box carrying CICP colour primaries,
transfer characteristics, and matrix coefficients was never read. This caused
HDR10 content to fall back to BT.709 in downstream decoders, rendering
near-black on HDR displays.

Populate the colour space fields from the NCLX colr box data when present.

Original Revision: https://phabricator.services.mozilla.com/D294849

Comment 34

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/b8a126c11c3a
https://hg.mozilla.org/releases/mozilla-beta/rev/3be4ad577b95
https://github.com/mozilla-firefox/firefox/commit/640e150b2f39
https://hg.mozilla.org/releases/mozilla-beta/rev/4cfd2d1e8717

Comment 35

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Tried verifying the fix on Firefox 152.0a1 (2026-04-22) - Windows 10, on the same system the issue was reported and unfortunately this is still happening. Here's a new video with the behavior.

Comment 36

[Alastor Wu [:alwu]]

Could you please capture another media profile? In addition, in your video, the video was recovered after resizing the window? If so, could you capture two cases, one for broken, one for restoring after resizing? Thanks!

Comment 37

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Here's the capture.

Comment 38

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: 20260423104226.all.log

And here's the log along with another media capture.

Comment 39

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 3: Fix mContentIsHDR to check transfer function, not just pixel format.

10-bit SDR video (e.g. BT.2020 wide color gamut with a standard gamma transfer
function) decodes to P010 format. Previously, mContentIsHDR was set based solely
on pixel format, so any P010 content was unconditionally treated as HDR.

On HDR monitors (mUseHDR = true), mContentIsHDR drives GetSwapChainFormat() to
select an HDR swap chain format (e.g. DXGI_FORMAT_R10G10B10A2_UNORM) and
GetOutputDXGIColorSpace() to configure the video processor for HDR10 output.
When the source content is actually SDR, GetSourceDXGIColorSpace() correctly
identifies the input as G22 (SDR BT.2020) via the transfer function, but the
output is still configured for HDR10 due to mContentIsHDR being true. This
mismatch between the SDR input color space and the HDR output configuration
causes incorrect video rendering. The issue does not occur on SDR monitors
because mUseHDR is false there, so the HDR swap chain paths are never taken.

Fix by also checking the transfer function: only PQ, HLG, and LINEAR transfer
functions indicate true HDR content. For 10-bit SDR content this means the swap
chain is created in SDR format (BGRA8), which correctly avoids the HDR processing
path. Note: this means 10-bit SDR wide color gamut content is rendered at 8-bit
output quality rather than 10-bit; properly preserving 10-bit for SDR WCG would
require a distinct swap chain path and is left for future work.

Comment 40

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 4: Use VideoInfo color space in ChromiumCDMParent instead of DefaultColorSpace heuristic.

For Widevine L3 (software CDM), the CDM outputs raw CPU YUV planes and
ChromiumCDMParent::CreateVideoFrame assembles them into a VideoData frame.
mYUVColorSpace was set via DefaultColorSpace(), which returns BT.601 (<720p)
or BT.709 (>=720p) based solely on frame height and never returns BT.2020.

For BT.2020 content this wrong value propagates through YCbCrDescriptor to
TextureHost::PushDisplayItems, which passes it directly to WebRender's YUV
shader as the color matrix, causing the wrong matrix to be used for YUV-to-RGB
conversion. This could cause incorrect colors or visible corruption.

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/92e66f1ed25a
https://hg.mozilla.org/integration/autoland/rev/06600688fb95
Part 3: Fix mContentIsHDR to check transfer function, not just pixel format. r=ahale
https://github.com/mozilla-firefox/firefox/commit/21f6d36d8599
https://hg.mozilla.org/integration/autoland/rev/b4f89c2748fb
Part 4: Use VideoInfo color space in ChromiumCDMParent instead of DefaultColorSpace heuristic. r=ahale
https://github.com/mozilla-firefox/firefox/commit/4dab6a935b7e
https://hg.mozilla.org/integration/autoland/rev/2184a4271536
apply code formatting via Lando

Comment 42

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 43

[Alastor Wu [:alwu]]

Could you help verify the fix again? It should be included in Nightly tomorrow, thanks!

Comment 44

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/06600688fb95
https://hg.mozilla.org/mozilla-central/rev/b4f89c2748fb
https://hg.mozilla.org/mozilla-central/rev/2184a4271536

Comment 45

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that Netflix now works on Windows 10 and Firefox 152.0a1 (2026-04-26). Waiting for it to be uplifted on beta.

Comment 46

[Donal Meehan [:dmeehan]]

:alwu, can you add beta uplift requests?
It's tricky to track since more than one stack was landed on the same bug, e.g. Comment 42

Comment 47

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Netflix playback corrupted
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Small changes to use correct color format to render the video frames, it doesn't introduce new features or behavior changes.
• String changes made/needed?: No.
• Is Android affected?: no

Comment 48

[Alastor Wu [:alwu]]

Attachment: Bug 2030296 - Part 3: Fix mContentIsHDR to check transfer function, not just pixel format.

10-bit SDR video (e.g. BT.2020 wide color gamut with a standard gamma transfer
function) decodes to P010 format. Previously, mContentIsHDR was set based solely
on pixel format, so any P010 content was unconditionally treated as HDR.

On HDR monitors (mUseHDR = true), mContentIsHDR drives GetSwapChainFormat() to
select an HDR swap chain format (e.g. DXGI_FORMAT_R10G10B10A2_UNORM) and
GetOutputDXGIColorSpace() to configure the video processor for HDR10 output.
When the source content is actually SDR, GetSourceDXGIColorSpace() correctly
identifies the input as G22 (SDR BT.2020) via the transfer function, but the
output is still configured for HDR10 due to mContentIsHDR being true. This
mismatch between the SDR input color space and the HDR output configuration
causes incorrect video rendering. The issue does not occur on SDR monitors
because mUseHDR is false there, so the HDR swap chain paths are never taken.

Fix by also checking the transfer function: only PQ, HLG, and LINEAR transfer
functions indicate true HDR content. For 10-bit SDR content this means the swap
chain is created in SDR format (BGRA8), which correctly avoids the HDR processing
path. Note: this means 10-bit SDR wide color gamut content is rendered at 8-bit
output quality rather than 10-bit; properly preserving 10-bit for SDR WCG would
require a distinct swap chain path and is left for future work.

Original Revision: https://phabricator.services.mozilla.com/D296170

Comment 49

[Alastor Wu [:alwu]]

Just submitted new uplift request, please uplift both part3 and part4. Thanks!

Comment 50

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c6aa851d9b58
https://hg.mozilla.org/releases/mozilla-beta/rev/baef6f7c5e1f
https://github.com/mozilla-firefox/firefox/commit/959e463dea36
https://hg.mozilla.org/releases/mozilla-beta/rev/d814de4dbdf2
https://github.com/mozilla-firefox/firefox/commit/039dc1875f99
https://hg.mozilla.org/releases/mozilla-beta/rev/76ed570f8ab6

Comment 51

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that the issue is fixed as well on Firefox 151.0b5 on the same machine.