Steps to reproduce

1. set: webgl.out-of-process to true
2. access: https://cesium.com/ion/stories/viewer/?id=2f0131ab-3948-4467-947c-411d5705a116

Notes:

• crash encountered on device with GPU - ATI Radeon 3000, but on others the page/test was loaded

This bug is for crash report bp-20483e28-7aef-4930-a626-23f660200724.

Top 10 frames of crashing thread:

0 xul.dll mozilla::gfx::Swizzle_SSE2<1, 0> gfx/2d/SwizzleSSE2.cpp:377
1 xul.dll mozilla::gfx::SwizzleData gfx/2d/Swizzle.cpp
2 xul.dll static gfxUtils::ConvertBGRAtoRGBA gfx/thebes/gfxUtils.cpp:261
3 xul.dll mozilla::WebGLContext::FrontBufferSnapshotInto dom/canvas/WebGLContext.cpp:1079
4 xul.dll mozilla::dom::WebGLParent::RecvGetFrontBufferSnapshot dom/canvas/WebGLParent.cpp:98
5 xul.dll mozilla::dom::PWebGLParent::OnMessageReceived ipc/ipdl/PWebGLParent.cpp:365
6 xul.dll mozilla::layers::PCompositorManagerParent::OnMessageReceived ipc/ipdl/PCompositorManagerParent.cpp:498
7 xul.dll mozilla::ipc::MessageChannel::DispatchSyncMessage ipc/glue/MessageChannel.cpp:2119
8 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2070
9 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953

I don't think we intend to ship WebGL remoting in 80, do we, Jeff?

(In reply to Andrew Overholt [:overholt] from comment #1)

I don't think we intend to ship WebGL remoting in 80, do we, Jeff?

Nope, only looking forward on this.

I think this was fixed by bug 1659874.
We'll watch crash reports to see if it's fixed on 81beta.

We've gotten a couple crashes still, even on Betas with bug 1659874 fixed.

Encountered the same crash with 83.0a1(2020-10-08) on Win10:
https://www.shadertoy.com/view/3slcWr

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

I took a look into this report: https://crash-stats.mozilla.org/report/index/c20ebfcf-9e69-4422-af0c-4e5cb0210411

WebGLParent::RecvGetFrontBufferSnapshot is computing a 0x0 size from mHost->GetFrontBufferSize();, which still allocates a shmem successfully.

WebGLContext::FrontBufferSnapshotInto computes a non-empty size from mSwapChain.FrontBuffer()->mDesc.size (401568x1).

I think this would have hit the assert MOZ_ASSERT(dest.length() == stride * size.height) in a debug build.

Looks like this is the #4 topcrash in the GPU process.

Previously we called GetFrontBufferSize, alloc'd a buffer, and called
FrontBufferSnapshotInto to read into the buffer.
Now, call FrontBufferSnapshotInto({}) to get size, and then alloc and
pass pointer to newly alloc'd data into
FrontBufferSnapshotInto(Some(ptr)).
Using the same function for both means that logic can't diverge and
cause mismatch bugs.

Backed out changeset 1331f134a250 (Bug 1655000) for causing bustages in WebGLContext.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/089f9acba4eef04aaa9920365e8398fe0984328b
Push with failures, failure log.

https://hg.mozilla.org/mozilla-central/rev/497a9e22d0ce

The patch landed in nightly and beta is affected.
:jgilbert, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

The volume is not insignificant on the release channel, let's see if we can uplift it, Jeff could you request the uplift please? thanks

Comment on attachment 9218829 [details]
Bug 1655000 - Use same function for getting size as reading into buffer.

Beta/Release Uplift Approval Request

• User impact if declined: Crashes, not-insignificant volume
• Is this code covered by automated tests?: No
• 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): Changes constrained to just a couple functions
• String changes made/needed: none

Comment on attachment 9218829 [details]
Bug 1655000 - Use same function for getting size as reading into buffer.

Approved for 89.0b14.

https://hg.mozilla.org/releases/mozilla-beta/rev/55e81873d600

I have managed to reproduce this issue on Release v88.0.1 and Beta v88.0b4; The behavior is: The page is loaded, then if the user attempts to zoom or interact with the website, the whole screen would turn black for 1 or 2 seconds, the website would show an error or it would crash completely.
A crash with the same crash signature would be recorded.

While attempting to verify the fix, I have attempted reproduction on Beta v89.0b14 and Nightly v90.0a1. The behavior is as follows: The page is loaded, then if the user attempts to zoom or interact with the website, the whole screen would turn black for 1 or 2 seconds and the page would show an error, but it does never really crash completely or record a crash report.

Based on the above, I can verify this fix, as it does not technically crash anymore, but the website is still unusable In any Firefox build.
Jeff, Should I log another bug for the remaining incorrect behavior?

The website displays the same error for both the affected and unaffected builds:
"Whoops
There was an unexpected error and this story cannot be loaded."

File a bug, I guess! :)

The bug is verified and the website is now properly usable with Release 91, Beta 91 RC, and Nightly 93.
The previously mentioned error is no longer reproduced. Please set a "need info request" when expecting to respond to a comment. Thanks!