Closed Bug 1609238 Opened 4 years ago Closed 4 years ago

canvas.transferControlToOffscreen() throws "NS_ERROR_NOT_IMPLEMENTED" Exception

Categories

(Firefox :: Untriaged, defect)

74 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1390089

People

(Reporter: guest271314, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

  1. about:config set gfx.offscreencanvas.enabled
  2. Execute canvas.transferControlToOffscreen()

Actual results:

Throws NS_ERROR_NOT_IMPLEMENTED Exception

Expected results:

NS_ERROR_NOT_IMPLEMENTED Exception should not be thrown

--

Appears to be a regression from https://bugzilla.mozilla.org/show_bug.cgi?id=1598998 ?

We do not get to NS_ERROR_FAILURE at canvas.width = 1000 described at https://bugzilla.mozilla.org/show_bug.cgi?id=1389090 before the NS_ERROR_NOT_IMPLEMENTED Exception is thrown.

Components:

  • Canvas: WebGL
  • Canvas: 2D

Thanks for the report!
Unfortunately we've stopped exposing support for transferControlToOffscreen for now, even with the pref.
Bug 1390089 tracks the work to re-enable it.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

(In reply to Jeff Gilbert [:jgilbert] from comment #1)

Thanks for the report!
Unfortunately we've stopped exposing support for transferControlToOffscreen for now, even with the pref.
Bug 1390089 tracks the work to re-enable it.

*** This bug has been marked as a duplicate of bug 1390089 ***

Was any documentation published to announce the stoppage of supporting transferControlToOffscreen()?

Or is your response the only official Firefox documentation of the removal of support for the method?

Your reply does not disclose any reasoning behind the decision to not expose support for transferControlToOffscreen(). Particularly after the work done by Sotaro Ikeda [:sotaro] re OffscreenCanvas.

Can you kindly provide sunstantive reasons for regressing to not expose transferControlToOffscreen()?

OffscreenCanvas will be a priority for us later this year. However, its current prototype is behind a pref, for which we don't guarantee such experimental features are free from breakage. Unfortunately, at present, we don't guarantee that this prototype is free from regressions. Maintaining support for the previous partial implementation has cost, particularly as we're moving our canvas implementations out of the sandboxed content process.

That rationale can apply to any number of Firefox implementations, for example mozCaptureStream(), media.getusermedia.audiocapture.enabled, etc.

What is the cost of exposing the partial implementation while developing new models?

Have been attempting to test OffscreenCanvas implementation at the front-end. Would have been helpful to have a heads up, particularly after the work done by Sotaro Ikeda [:sotaro], which are now for naught?

That's the risk with these behind-a-pref prototypes, unfortunately. This is a patches-welcome scenario, but we also can't prioritize fixing or maintaining this over other pressing work right now. Patches fixing anything in prototypes today may break tomorrow with no notice, as with this bug. I'm sorry I don't have anything more reassuring to say here.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: