1910990 - drag and drop of local video files onto x.com / twitter.com page for posting causes page content to go blank and tab to be broken in late beta and upcoming release

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P1)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox 129.0 release candidate 1, based on bisection late beta builds are affected. Windows 10

Drag and drop of local video files onto x.com page for posting causes page content to go blank and tab to be broken in late beta and upcoming release.

0. Have an account at x.com
1. Open https://x.com/home
2. In the left sidebar, click the 'Post' button.
3. Drag and drop a local video file into the area where the new post gets composed.

Actual results:

• Whole browser window goes blank for a short time.
• Content area of tab is blank
• Entering urls into the location bar and attempts to load them will fails (nothing happens)
• menu Tools > Browser Tools > Browser Console opens but fails to load console message

Expected:

• thumbnail for video shown
• video gets uploaded

This issue can be reproduced with videos uploaded successfully before with Firefox 128.0.x builds.

Other observations:

• Dragging and dropping images into the Compose area first, cancelling the composition and then starting a new one with the video dragged and dropped works as expected.
• If the Browser Toolbox is enabled, drag and drop of the video works as expected, even if the option 'Disable Cache' is not active.
• Toggling the options media.hls.enabled and media.eme.playready.enabled did not change behavior.
• Drag and drop of a video at https://imgur.com/upload works as expected but that site does not try to show a video thumbnail during upload.

Do you have further ideas how to debug this and which preference could alter the behavior in late beta and release?

Comment 1

[Karl Tomlinson (:karlt)]

Selecting the "Media playback" "Logging preset" on about:logging and logging to the profiler might capture something helpful.
Include hidden threads when uploading. Screenshots might be helpful too.

Video code should not be affecting location bar interactivity, but perhaps something in the parent process might be surprised by a change in video processing behavior.

Comment 2

[Karl Tomlinson (:karlt)]

Logging is unlikely to capture what is going wrong in front-end code.
I'd try opening the Browser Toolbox at a later time.

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Profiler: https://share.firefox.dev/4do8U3x
If the file does not get dragged and dropped but selected with the file picker launched from the compose area, there are no issues observed.

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Nightly notified me now (after a restart post-update) about unsubmitted crash reports. The stack points a canvas issue.

The stack points to bug 1903047 as regressing change.

Comment 5

[Sotaro Ikeda [:sotaro]]

I take the bug.

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Sorry, had not posted the crash report in comment 4: bp-eebcd962-93c9-4f64-ae01-28ea70240801

Comment 7

[Sotaro Ikeda [:sotaro]]

I could not reproduce the problem with my Win11 PC with NVIDIA GPUs. The basic query handling was added by Bug 1817617.

The query is used with the followings

• [1] hardware video decoding
• [2] reuse decoder device is used for hardware video decoding
• [3] zero copy video frame is not enabled.

[2] always happens on AMD GPUs in DeviceManagerDx::CreateDecoderDevice()

Comment 8

[Sotaro Ikeda [:sotaro]]

The problem might happen with specific AMD GPUs.

Comment 9

[Sotaro Ikeda [:sotaro]]

:aryx, can you attach about:support to this bug?

Comment 10

[Sotaro Ikeda [:sotaro]]

If the problem happens only with AMD GPUs, it seems better to disable Canvas 2d video rendering optimization if GpuProcessQueryId exists with AMD GPUs for now.

Comment 11

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1910990 - Don't use ID3D11Query to wait for video copy complete for remote canvas. with AMD GPUs

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: aboutSupport-bug1910990.txt

Comment 13

[Sotaro Ikeda [:sotaro]]

:aryx, can you check if the following build addresses the problem for you?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/al_n--CJSXqWN_ZpZsvGYg/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
https://treeherder.mozilla.org/jobs?repo=try&revision=3dc46ebb735c2021047809ff8973c14d3a6b225d

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

That is a build based on Nightly and the issue is only observed for late beta builds and release. Is it correct this requires a try build based on release to verify the changes fixes it?

Comment 15

[Sotaro Ikeda [:sotaro]]

:aryx, can you test with pref media.wmf.zero-copy-nv12-textures = false in about:config? It is affected by Bug 1899450. Sorry, I forgot to mention about it.

Even with default nightly, pref media.wmf.zero-copy-nv12-textures = false in about:config should cause the problem with AMD GPUs.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a75fa02a9407
Don't use ID3D11Query to wait for video copy complete for remote canvas. with AMD GPUs r=gfx-reviewers,lsalzman

Comment 17

[Sotaro Ikeda [:sotaro]]

:ahale confirmed the problem is addressed with D218390.

Comment 18

[Sotaro Ikeda [:sotaro]]

Comment on attachment 9417426 [details]
Bug 1910990 - Don't use ID3D11Query to wait for video copy complete for remote canvas. with AMD GPUs

Beta/Release Uplift Approval Request

• User impact if declined: Crash happens with STR of Bug 1910990 with AMD GPUs when hardware video decoding is used without zero copy video.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• 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): The change reverts to already used slow path with AMD GPUs.
• String changes made/needed: none
• Is Android affected?: No

Comment 19

[Iulian Moraru]

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

Comment 20

[Donal Meehan [:dmeehan]]

Comment on attachment 9417426 [details]
Bug 1910990 - Don't use ID3D11Query to wait for video copy complete for remote canvas. with AMD GPUs

Fx129 is in release, switch beta uplift request to release for inclusion in a later dot release

Comment 21

[Peter Magyari (Desktop QA)]

I have reproduced the issue using Firefox 129.0 (20240729133145) and verified the fix using Firefox 130.0a1 (20240803095257) on a PC with a Radeon Rx550 GPU.

Comment 22

[Donal Meehan [:dmeehan]]

Comment on attachment 9417426 [details]
Bug 1910990 - Don't use ID3D11Query to wait for video copy complete for remote canvas. with AMD GPUs

Approved for 129.0.1

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/710f1a644b97

Comment 24

[Peter Magyari (Desktop QA)]

I have verified the fix using Firefox 129.0.1 (20240812083151) on Windows 10 with AMD Rx550 GPU.