"Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)

[jinzo7]

Hello!

The project is old so PIXI v.3.0.11 is used.
For streaming - Flashphoner via WebRTC

Steps to reproduce

1. Start video stream in html video element - stream.start(myDiv) which creates streamVideoElement in myDiv

2. When stream fires STREAM_PLAYING event the method PIXI.Texture.fromVideo(streamHtmlVideoElement) is called and the returned texture is set to the specific PIXI.Sprite instance.

3. Somewhere after this the Firefox browser receives error thrown by WebGl:

Additional information

• The problem is happened very rerely
• Only Firefox
• Stream(video element) is not failed after the error

Quote

 

SecurityError: The operation is insecure. pixi.js:14771

    updateTexture pixi.js:14771

    renderBatch pixi.js:18735

    flush pixi.js:18661

    renderWebGL pixi.js:7724

    renderWebGL pixi.js:7769

    renderWebGL pixi.js:7769

    renderWebGL pixi.js:7769

    renderWebGL pixi.js:7769

    renderDisplayObject pixi.js:14682

    render pixi.js:14655

    animate Stage.ts:385

    animate Stage.ts:388

 

 

In the PIXI source code that means:

gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, texture.source);

What we tried

• tried to set  video.crossOrigin = "anonymos" to the video element but no success.
• tried to dispose video like video.src = "" and etc according some advices related to the localStorage caching

I know it's not directly linked by PIXI but still I need help.

And the image of the current block when exception was thrown.

 

[ivan.popelyshev]

> I know it's not directly linked by PIXI but still I need help.

You're very humble, I pinged people who have experience with videos in pixijs to help you  

[Exca]

That looks like a CORS problem. Can you check what network headers the video (and possibly related preflight request) have in relation to access control?

[jinzo7]

52 minutes ago, Exca said:

That looks like a CORS problem. Can you check what network headers the video (and possibly related preflight request) have in relation to access control?

The only headers I can access is the updgrading protocol request/response (from http to ws) wich does not contains any valuable information. After this the connection is opened between my client and the server. The client receives only socket messages like stream events - PLAY, FAIL and etc.

I cannot inspect the WebRTC headers and messages at whole. Also cannot find any tool that can do this.

The problem is happening very rarely and it is in Firefox only. So in one moment I decided to stop believing it is CORS problem for that reason.

And only WebGl has problem. The stream(video element) is not failed or something.

[Exca]

Do you draw something else than the video to canvas? If something taints a canvas then it stays tainted no matter what is rendered in the future. Or it might be due to stream becoming unavailable at some point for short duration and that could cause tainting (though the bug report I found on this should be already resolved, it was 5 years ago).

Pretty sure it's some kind of edge case in security constraints which causes canvas to become tainted (by something), which causes security error when pixels are read from it.

[jinzo7]

Said in that way sounds very trustworthy.

Okay I will make more research around. Think the Firefox forum will be affected too.

Thank you very much! I will write when something new emerges on the horizon !

[Exca]

You could create a simple test case where you have a canvas, you draw the video there and then read a single pixel from it. If it gives the same error, then the video causes tainting. If not, then it's something else.