Closed Bug 1627594 Opened 4 years ago Closed 4 years ago

WebGL content fails to paint before browser interaction is made. (demo: Tiny3d)

Categories

(Core :: Graphics: CanvasWebGL, defect, P2)

76 Branch
Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- disabled
firefox76 --- disabled
firefox77 --- verified

People

(Reporter: atrif, Assigned: mikokm)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

Attached image blank_page.gif

Affected versions

  • 76.0a1 (20200405212522)

Affected platforms

  • Windows 10 x64
  • Ubuntu 18.04

Preconditions

  • enable dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled=true

Steps to reproduce

  1. Open Firefox and go to http://clb.confined.space/dump/unity/tiny3d-asmjs-tiny3d/Tiny3D.html.

Expected result

  • Page loads successfully.

Actual result

  • A blank page is displayed (content is shown only after a browser interaction e.g: clicking the address bar or opening web console or focusing away from the browser)

Regression Range

  • I will search for one ASAP if there is one.

Notes

  • Attached a screen recording with the issue.
  • It seems that on Ubuntu 18 the content is loaded for the first time after 5-6 seconds but the same behavior occurs when reloading the page.
  • On macOS 10.12 content is loaded as expected so I think macOS is not affected.
  • Attached the web console log.
Has Regression Range: --- → no
Has STR: --- → yes

Attaching here the pushlog when the good build loads the page as expected without a browser interaction and the bad build doesn't load the page at all (sometimes just a green page is presented and A web page is slowing down your browser. What do you like to do? banner message is displayed).

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=63dba0113913913e77122ff7c3a42760c732c35b&tochange=f2b77060cc80e064f5095a2f06690e7c5d32289a

If more information is needed please let me know.

Has Regression Range: no → yes

Thanks for the precise pushlog, Alexandru!

Edgar, were your changes from bug 1575425 intended to make WebGL content not work until post user-interaction?

Flags: needinfo?(echen)

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

Edgar, were your changes from bug 1575425 intended to make WebGL content not work until post user-interaction?

No, bug 1575425 just implemented [AllowShared] in webidl to ensure that develop could not pass a SharedArrayBuffer to the API that doesn't support. In theory, it should not change the WebGL content behaviour.

(In reply to Alexandru Trif, QA [:atrif] from comment #0)

Actual result

  • A blank page is displayed (content is shown only after a browser interaction e.g: clicking the address bar or opening web console or focusing away from the browser)

Or resize the window.

Jeff, maybe you have some idea about what's happened. Thanks!

Flags: needinfo?(echen) → needinfo?(jgilbert)

This is unexpected, we've made no such change.

Flags: needinfo?(jgilbert)
Summary: Content not loading until a browser interaction is made → WebGL content fails to paint before browser interaction is made. (demo: Tiny3d)

(In reply to Edgar Chen [:edgar] from comment #3)

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

Edgar, were your changes from bug 1575425 intended to make WebGL content not work until post user-interaction?

No, bug 1575425 just implemented [AllowShared] in webidl to ensure that develop could not pass a SharedArrayBuffer to the API that doesn't support. In theory, it should not change the WebGL content behaviour.

But does the page somehow relied on the old behavior?

Flags: needinfo?(echen)

The bug 1575425 actually makes the test page stay black and browser seems stuck (reloading or trying to load another URI is responseless). And then after bug 1615741, the page failed with

TypeError: WebGL2RenderingContext.uniformMatrix4fv: Float32Array branch of (Float32Array or sequence) can't be a SharedArrayBuffer or an ArrayBufferView backed by a SharedArrayBuffer

And bug 1624944 fixes the error, and page could be rendered again, but somehow it something requires a post user-interaction.
I review all of those three path a again, I still have no idea how those patches make the test page requires a post user-interaction.

I suspect maybe there are some changes in-between https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=63dba0113913913e77122ff7c3a42760c732c35b&tochange=f2b77060cc80e064f5095a2f06690e7c5d32289a (which make the page doesn't work at all) and https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=59b0653948b4c32e0b1053f29e87ec0e841da17f&tochange=e2fe93a06bf5c3c7a04cca1cb1b145f765504d18 (which make the page could be rendered again) cause such behavior.

(In reply to Edgar Chen [:edgar] from comment #7)>

I could try if I could narrow down the range a bit locally.

I have narrowed down the range to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=97385d484fbf&tochange=7210a39affab and it smells like https://hg.mozilla.org/integration/autoland/rev/57b9344a88a3250ee0924a4ecf7a27b986b050fd.

Okay, so It look like the bug 1617754 makes test content not work until post user-interaction. Could you take a look, Miko. Thanks

Flags: needinfo?(echen) → needinfo?(mikokm)

(In reply to Edgar Chen [:edgar] from comment #9)

Okay, so It look like the bug 1617754 makes test content not work until post user-interaction. Could you take a look, Miko. Thanks

I can only reproduce this intermittently, but I think you are correct.

Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Flags: needinfo?(mikokm)

The patch for bug 1617754 removed some (usually redundant) calls to nsIFrame::SchedulePaint() with WebRender. I believe this uncovered an existing bug with WebRender canvas invalidation1, which attempts to do empty transaction before WebRender has processed the display list with the canvas display item.

Priority: -- → P2
Pushed by mikokm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/3052e065c816
Schedule a full paint when canvas element is invalidated before the first paint r=kats
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Verified the issue using Firefox 77.0a1 (20200503214759) on Windows 10x64, macOS 10.12 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.