OffscreenCanvas from transferControlToOffscreen not visible, width and height not set at <canvas> following executing transferFromImageBitmap(imageBitmap)
Categories
(Core :: Graphics: Canvas2D, defect, P3)
Tracking
()
People
(Reporter: guest271314, Assigned: sotaro)
References
()
Details
Attachments
(4 files)
requested image
|
Reporter | |
Comment 1•5 years ago
|
||
|
||
Comment 2•5 years ago
|
||
Hi,
I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one. Could be also Canvas: WebGL.
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 3•5 years ago
|
||
Looked into m-c source. It seems that offscreencanvas rendering of ImageBitmapRenderingContext is not implemented yet. There is a code for offscreen WebGL rendering. But it seemed to be broken now.
|
|
Reporter | |
Comment 4•5 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #3)
Looked into m-c source. It seems that offscreencanvas rendering of ImageBitmapRenderingContext is not implemented yet. There is a code for offscreen WebGL rendering. But it seemed to be broken now.
By rendering do you mean displaying the image?
What is the barrier to implementation?
|
|
Assignee | |
Comment 5•5 years ago
|
||
(In reply to guest271314 from comment #4)
(In reply to Sotaro Ikeda [:sotaro] from comment #3)
Looked into m-c source. It seems that offscreencanvas rendering of ImageBitmapRenderingContext is not implemented yet. There is a code for offscreen WebGL rendering. But it seemed to be broken now.
By rendering do you mean displaying the image?
Yes.
What is the barrier to implementation?
Update HTMLCanvasElement, OffscreenCanvas and AsyncCanvasRenderer as to handle Offscreencanvas ImageBitmap.
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 7•5 years ago
|
||
let canvas = document.createElement("canvas");
let offscreen = canvas.transferControlToOffscreen();
let ctx = offscreen.getContext("bitmaprenderer");
console.log(ctx.canvas); // undefined at Firefox, OffscreenCanvas instance at Chromium
Should canvas property of rendering context point to OffscreenCanvas instance?
Do the changes address that omission?
|
|
Assignee | |
Comment 8•5 years ago
|
||
(In reply to guest271314 from comment #7)
Should
canvasproperty of rendering context point toOffscreenCanvasinstance?Do the changes address that omission?
ImageBitmapRenderingContext.webidl does not define canvas attribute. It seems like a bug. Can you create a new bug for it? Thanks.
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/dom/webidl/ImageBitmapRenderingContext.webidl#19
https://html.spec.whatwg.org/multipage/canvas.html#imagebitmaprenderingcontext
|
|
Reporter | |
Comment 9•5 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #8)
(In reply to guest271314 from comment #7)
Should
canvasproperty of rendering context point toOffscreenCanvasinstance?Do the changes address that omission?
ImageBitmapRenderingContext.webidl does not define canvas attribute. It seems like a bug. Can you create a new bug for it? Thanks.
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/dom/webidl/ImageBitmapRenderingContext.webidl#19
https://html.spec.whatwg.org/multipage/canvas.html#imagebitmaprenderingcontext
|
|
Assignee | |
Comment 10•5 years ago
|
||
|
||
Comment 11•5 years ago
|
||
Pushed by sikeda.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/67142a370d4a Fix CanvasContextType::ImageBitmap handling r=nical
|
||
Comment 12•5 years ago
|
||
Backed out changeset 67142a370d4a for causing failures in ImageBitmapRenderingContext.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/847d77fecedc2722c54223105f2ec1e5c56c290b
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=283730388&repo=autoland&lineNumber=34560
[task 2020-01-06T23:35:35.629Z] 23:35:35 INFO - TEST-START | dom/canvas/test/test_bitmaprenderer.html
[task 2020-01-06T23:35:35.706Z] 23:35:35 INFO - GECKO(2165) | [Parent 2165, Main Thread] WARNING: we only accept nsIURI interface type, patch welcome: file /builds/worker/workspace/build/src/dom/ipc/PropertyBagUtils.cpp, line 112
[task 2020-01-06T23:35:35.706Z] 23:35:35 INFO - GECKO(2165) | [Child 2167, Main Thread] WARNING: Trying to request nsIHttpChannel from DocumentChannelChild, this is likely broken: file /builds/worker/workspace/build/src/netwerk/ipc/DocumentChannelChild.cpp, line 64
[task 2020-01-06T23:35:35.758Z] 23:35:35 INFO - GECKO(2165) | [Child 2167, Main Thread] WARNING: NS_ENSURE_TRUE(nsContentUtils::IsJavascriptMIMEType(type)) failed: file /builds/worker/workspace/build/src/dom/script/ScriptLoader.cpp, line 1558
[task 2020-01-06T23:35:35.841Z] 23:35:35 INFO - GECKO(2165) | [Child 2167, Main Thread] WARNING: Workers don't support the 'mem.mem.' preference!: file /builds/worker/workspace/build/src/dom/workers/RuntimeService.cpp, line 537
[task 2020-01-06T23:35:35.861Z] 23:35:35 INFO - GECKO(2165) | Assertion failure: imageContainer, at /builds/worker/workspace/build/src/dom/canvas/ImageBitmapRenderingContext.cpp:264
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO - GECKO(2165) | #01: mozilla::dom::ImageBitmapRenderingContext::TransferFromImageBitmap(mozilla::dom::ImageBitmap&) [dom/canvas/ImageBitmapRenderingContext.cpp:0]
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO - GECKO(2165) | #02: mozilla::dom::ImageBitmapRenderingContext_Binding::transferFromImageBitmap(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [s3:gecko-generated-sources:a602670226c1ea539a0b940ff9d6d92e5d9ef9282326da19bd60c50e1fc1bed19a8cc4f5c3eba297e7802c3cee867240ee7597f76fc64acd3e11cae9e80dab9d/dom/bindings/ImageBitmapRenderingContextBinding.cpp::54]
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO - GECKO(2165) | #03: bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) [dom/bindings/BindingUtils.cpp:3153]
[task 2020-01-06T23:36:00.556Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO - GECKO(2165) | #04: CallJSNative(JSContext*, bool ()(JSContext, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) [js/src/vm/Interpreter.cpp:452]
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO - GECKO(2165) | #05: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [js/src/vm/Interpreter.cpp:544]
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO - GECKO(2165) | #06: Interpret(JSContext*, js::RunState&) [js/src/vm/Interpreter.cpp:3038]
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO - GECKO(2165) | #07: js::RunScript(JSContext*, js::RunState&) [js/src/vm/Interpreter.cpp:424]
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO - GECKO(2165) | #08: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [js/src/vm/Interpreter.cpp:580]
[task 2020-01-06T23:36:00.557Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO - GECKO(2165) | #09: <name omitted> [js/src/vm/Interpreter.cpp:625]
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO - GECKO(2165) | #10: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2769]
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO - GECKO(2165) | #11: mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) [s3:gecko-generated-sources:07034a91c20d743b6b1cb0050fb45856e506111933106e79effdb8dcee60d394334ccec99923dca240d02a8a2423627e46882951c1689b39a2e7f0665bac7e9b/dom/bindings/EventHandlerBinding.cpp::267]
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO - GECKO(2165) | #12: void mozilla::dom::EventHandlerNonNull::Call<nsCOMPtr<mozilla::dom::EventTarget> >(nsCOMPtr<mozilla::dom::EventTarget> const&, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) [s3:gecko-generated-sources:6d3b05f83d6cfb57de46f6a8a17ade674231234ad1eee8cecd121ed28c64b097a8c2c5430ace56b853c13671fef98ed7efe23efef511ea77c3c0e4e0bf3983eb/dist/include/mozilla/dom/EventHandlerBinding.h::365]
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO -
[task 2020-01-06T23:36:00.558Z] 23:36:00 INFO - GECKO(2165) | #13: mozilla::JSEventHandler::HandleEvent(mozilla::dom::Event*) [dom/events/JSEventHandler.cpp:201]
|
|
Assignee | |
Comment 13•5 years ago
|
||
(In reply to Alexandru Michis [:malexandru] from comment #12)
Backed out changeset 67142a370d4a for causing failures in ImageBitmapRenderingContext.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/847d77fecedc2722c54223105f2ec1e5c56c290b
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=283730388&repo=autoland&lineNumber=34560
The assert was false alarm. We need to handle a case that mOffscreenCanvas->GetImageContainer() returns nullptr.
|
|
Assignee | |
Comment 14•5 years ago
|
||
The failure was addressed.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=13c90d49fa922add13bac3fb5e16e78319a2b1e3
|
|
||
Comment 15•5 years ago
|
||
Pushed by sikeda.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/176d3afceccb Fix CanvasContextType::ImageBitmap handling r=nical
|
||
Comment 16•5 years ago
|
||
| bugherder | ||
|
||
Comment 17•5 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
|
|
Assignee | |
Comment 18•5 years ago
|
||
Offscreencanvas is disabled by perf by default.
|
|
||
Comment 19•5 years ago
|
||
Hi,
@guest271314, could you please provide us some steps, maybe extra settings if there are any, in order to try to reproduce the initial issue on our side and verify the fix in latest Nightly build 74.0a1 ? Or if its easier for you to confirm that the bug is not reproducible anymore in latest Nightly build, you can find it here: https://nightly.mozilla.org , and report back the results?
Thanks.
|
|
Reporter | |
Comment 20•5 years ago
|
||
(In reply to Alin Ilea from comment #19)
Hi,
@guest271314, could you please provide us some steps, maybe extra settings if there are any, in order to try to reproduce the initial issue on our side and verify the fix in latest Nightly build 74.0a1 ? Or if its easier for you to confirm that the bug is not reproducible anymore in latest Nightly build, you can find it here: https://nightly.mozilla.org , and report back the results?
Thanks.
Running the attached files https://bugzilla.mozilla.org/attachment.cgi?id=9111135, https://bugzilla.mozilla.org/attachment.cgi?id=9111137 now does output display of the image at Nightly 74.0a1 observable at version 1 of https://plnkr.co/edit/eXESuVqOp5J9AAAft07E?p=preview.
canvas attribute is still not defined at ImageBitmapRenderingContext or OffscreenCanvas instances, respectively.
|
|
Reporter | |
Comment 21•5 years ago
|
||
Also, canvas.captureStream() throws and exception
Exception { name: "NS_ERROR_NOT_INITIALIZED", message: "", result: 3253927937, filename: "https://run.plnkr.co/klGdG4k1Cpo1c2W9/", lineNumber: 17, columnNumber: 0, data: null, stack: "worker.onmessage@https://run.plnkr.co/klGdG4k1Cpo1c2W9/:17:31\nEventHandlerNonNull*@https://run.plnkr.co/klGdG4k1Cpo1c2W9/:15:5\n" }
for
<canvas style="border:1px solid green"></canvas>
<video controls></video>
<script>
const canvas = document.querySelector("canvas");
const offscreen = canvas.transferControlToOffscreen();
const worker = new Worker("firefoxNightlyOffscreenCanvasNotVisibleIncorrectWidthAndHeightWorker.js");
worker.onmessage = e => {
try {
const stream = canvas.captureStream();
document.querySelector("video").srcObject = stream;
} catch(e) {
console.error(e);
}
const {
width, height
} = e.data;
console.log(offscreen.canvas);
const requestFrame = _ => {
if (canvas.width !== width && canvas.height !== height) {
console.assert(canvas.width === width && canvas.height === height, [width, height, canvas.width, canvas.height]);
requestAnimationFrame(requestFrame);
} else {
console.log(canvas.width === width && canvas.height === height, [width, height, canvas.width, canvas.height]);
}
}
requestAnimationFrame(requestFrame);
}
worker.postMessage({
offscreen
}, [offscreen]);
</script>
where Chromium 80 does not throw an exception, captures the media stream from the canvas, and draws one frame at <video>.
|
|
Reporter | |
Comment 22•5 years ago
|
||
For completeness, the assertion does fail at Chromium twice before the width and height of canvas change, and currentTime of <video> remains at 0, playback of the MediaStream does not proceed. AFAICT there is no specification for what should occur when canvas.transferControlToOffscreen() is executed, then canvas.captureStream()?
(index):25 Assertion failed: (4) [499, 259, 300, 150]
requestFrame @ (index):25
requestAnimationFrame (async)
worker.onmessage @ (index):31
(index):25 Assertion failed: (4) [499, 259, 300, 150]
requestFrame @ (index):25
requestAnimationFrame (async)
requestFrame @ (index):26
requestAnimationFrame (async)
worker.onmessage @ (index):31
(index):28 true (4) [499, 259, 499, 259]
|
|
Reporter | |
Comment 23•5 years ago
|
||
This https://bugzilla.mozilla.org/show_bug.cgi?id=1590030 describes the above notes re MediaStream to an appreciable degree. Getting closer to full functionality of OffscreenCanvas, however, it appears there is no standardized algorithm in any specification to handle canvas.transferControlToOffscreen() followed by canvas.captureStream() (https://github.com/web-platform-tests/wpt/issues/21102), that is, what precisely should occur when those two methods are called in sequence?
|
|
Reporter | |
Comment 24•5 years ago
|
||
(In reply to Alin Ilea from comment #19)
Hi,
@guest271314, could you please provide us some steps, maybe extra settings if there are any, in order to try to reproduce the initial issue on our side and verify the fix in latest Nightly build 74.0a1 ? Or if its easier for you to confirm that the bug is not reproducible anymore in latest Nightly build, you can find it here: https://nightly.mozilla.org , and report back the results?
Thanks.
This code throws an exception
let canvas = document.createElement("canvas");
let offscreen = canvas.transferControlToOffscreen();
[Exception... "Method not implemented" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 2" data: no]
If recollect correctly and per https://bugzilla.mozilla.org/show_bug.cgi?id=1598998#c7 the code did not throw an exception last month?
|
|
Reporter | |
Comment 25•5 years ago
|
||
|
|
||
Comment 26•5 years ago
|
||
Hi,
We tried to confirm this issue but after downloading the 2 files firefoxNightlyOffscreenCanvasNotVisibleIncorrectWidthAndHeight.html and firefoxNightlyOffscreenCanvasNotVisibleIncorrectWidthAndHeightWorker.js into the same folder and starting the HTML file in Firefox Nightly or Beta or Release we only see the same iFrame as in Chrome, we are not sure what it should be displayed, can you please confirm that this issue is fixed on your end so we can update the flags accordingly ? Maybe for more information you can needinfo the assignee..
Thanks.
|
|
Reporter | |
Comment 27•5 years ago
|
||
(In reply to Alin Ilea from comment #26)
Hi,
We tried to confirm this issue but after downloading the 2 files firefoxNightlyOffscreenCanvasNotVisibleIncorrectWidthAndHeight.html and firefoxNightlyOffscreenCanvasNotVisibleIncorrectWidthAndHeightWorker.js into the same folder and starting the HTML file in Firefox Nightly or Beta or Release we only see the same iFrame as in Chrome, we are not sure what it should be displayed, can you please confirm that this issue is fixed on your end so we can update the flags accordingly ? Maybe for more information you can needinfo the assignee..
Thanks.
20 days ago (https://bugzilla.mozilla.org/show_bug.cgi?id=1598998#c20) transferControlToOffscreen() was working, the core issue of this bug was resolved.
Now there is an NS_ERROR_NOT_IMPLEMENTED: exception being thrown when transferControlToOffscreen() is being executed.
Chromium 81 displays the ImageBitmap transferred to the OffscreenCanvas in the Worker in the <canvas> element in the main thread.
|
|
Reporter | |
Comment 28•5 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
Offscreencanvas is disabled by perf by default.
What changed? Now executing transferControlToOffscreen() throws a "NS_ERROR_NOT_IMPLEMENTED" exception.
|
|
||
Comment 29•5 years ago
|
||
(In reply to guest271314 from comment #28)
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
Offscreencanvas is disabled by perf by default.
What changed? Now executing
transferControlToOffscreen()throws a"NS_ERROR_NOT_IMPLEMENTED"exception.
This was probably bug 1477756.
|
|
Reporter | |
Comment 30•5 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #29)
(In reply to guest271314 from comment #28)
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
Offscreencanvas is disabled by perf by default.
What changed? Now executing
transferControlToOffscreen()throws a"NS_ERROR_NOT_IMPLEMENTED"exception.This was probably bug 1477756.
How is the linked bug related to transferControlToOffscreen() and the work previously done by Sotaro Ikeda [:sotaro]?
Trying to grasp why transferControlToOffscreen() is defined one day then not the next?
|
|
Reporter | |
Comment 31•5 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #29)
(In reply to guest271314 from comment #28)
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
Offscreencanvas is disabled by perf by default.
What changed? Now executing
transferControlToOffscreen()throws a"NS_ERROR_NOT_IMPLEMENTED"exception.This was probably bug 1477756.
Obviously with the decision to remove support for transferControlToOffscreen() this bug is no longer "fixed".
Can you kindly revert that status to open until whatever the as yet undisclosed issue with support the method is remedied?
Description
•