Closed Bug 339587 Opened 19 years ago Closed 16 years ago

content canvas getImageData always returns null from chrome context

Categories

(Core :: Graphics: Canvas2D, defect, P4)

Product:
Core
Component:
Graphics: Canvas2D
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: sendmail.to, Assigned: crowderbt)

References

Details

Attachments

(2 files)

XPI Testcase
2.08 KB, application/x-xpinstall
Details
The patch [Checkin: Comment 15]
677 bytes, patch
mrbkap
: review+
mrbkap
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3 ID:2006052903 Using the getImageData(sx, sy, sw, sh) Function from an Extension always fails. This js Code works from a webpage but not from an extension: <html> <head> <script type="application/x-javascript"> function draw() { var canv = window._content.document.getElementById('canvas'); var ctx = canv.getContext('2d'); ctx.fillStyle = "rgb(200,255,0)"; ctx.fillRect (0, 0, 300, 300); var gimg = ctx.getImageData(25,25,1,1); var data = gimg != null ? gimg.data : null; alert("Element: " + canv + "\n getcontext : " + ctx + "\ngetImageData(): " + gimg + "\ndata: " + data); } </script> </head> <body onload="draw()"> <canvas id="canvas" width="300" height="300"></canvas> </body> </html> Reproducible: Always Expected Results: Should return an ImageData structure. Tested in Alpha 3, and in the newest 1.8 nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3 ID:2006052903
Hmm, I'm not sure what's going on -- I'll check tomorrow, I need to create an extension to do something with it. If you have a testcase xpi that does this, it would be much appreciated if you could attach it :) (In reply to comment #1) > This IDL Definition looks wrong: > http://lxr.mozilla.org/mozilla1.8/source/dom/public/idl/canvas/nsIDOMCanvasRenderingContext2D.idl#128 > Line 133 and 134 The definition is correct; the methods obtain their arguments from the JS context. > And here i see no reference to getImageData/putImageData > http://lxr.mozilla.org/mozilla1.8/source/layout/xul/base/public/nsICanvasRenderingContext2D.idl That file needs to disappear, it's leftover droppings from an earlier misplaced canvas impl. It was cvs removed on the trunk, but not on the branch. (It's not even referenced in the makefile.
Attached file XPI Testcase —
(In reply to comment #2) > Hmm, I'm not sure what's going on -- I'll check tomorrow, I need to create an > extension to do something with it. If you have a testcase xpi that does this, > it would be much appreciated if you could attach it :) Simply install the xpi, and load the html Testcase above(from comment #1). Click then the Test Button(added to the Status Bar) to use the same js code from a chrome context.
Sorry, short correction: use html Testcase from comment #0 instead ;-)
The canvas element returned is an XPCNativeWrapper-wrapped DOMHTMLCanvasElement, as is the 2d rendering context. The problem seems to be that XPCNativeWrapper ignores any retval set on the XPCCallContext, which is the method that GetImageData() uses to return the imagedata object. XPC_WN_CallMethod uses XPCWrappedNative::CallMethod(ccx), which I believe correctly handles the ccx RetVal case; this gets called by XPC_NW_CallMethod, which has a different ccx on which the RetVal doesn't seem to be set. gonna need mrbkap's help on this one, I think.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ok, bad diagnosis. The problem is that XPCNW tries to wrap all the resulting objects with their own wrappers. But the object I return is just a generic js object with a few properties set (one of which contains a js array). There's no WrappedNative for this, so the code at http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/XPCNativeWrapper.cpp#300 nulls it out, and we all lose.
Note that this would work fine if the canvas you're calling was also part of chrome, as opposed to being part of content. The canvas is being wrapped because it's crossing the chrome -> content boundary, and that's where the problems start.
Summary: Canvas getImageData always returns null from Chrome context → content canvas getImageData always returns null from chrome context
Not sure what we want to do about this.
Priority: -- → P4
I have a patch for this, which is to cause an SJOW to be created for the ImageData object (which is really just a JSObject with an array and a couple properties hooked to it). Coming up...
The problem with my patch is that the now-wrapped ImageData object can't be used in putImageData, because the .data member is also being dynamically wrapped (and so, does not appear to be a JSArray).... more soon.
What is the fear in returning a raw JS object? Are we concerned that it will have content functions attached, which we might then execute with chrome privs? Would it be alright for JSObject/JSArray structures (ie., I'd have to traverse the object tree to make sure it is only those things) to pass through unwrapped?
Assignee: nobody → crowder
Status: NEW → ASSIGNED
Attachment #371695 - Flags: review?(mrbkap)
Incidentally, without my patch, there is an easy workaround: build your ImageData by hand from your content js: let imgData = { width: width, height: height }; imgData.data = new Array(width * height * 4); ... and so on.
Attachment #371695 - Flags: superreview+
Attachment #371695 - Flags: review?(mrbkap)
Attachment #371695 - Flags: review+
Very minor bug, though the workaround is not ideal... I'll file another bug on making JS_IsArrayObject check for a wrapped inner object.
Severity: major → minor
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: checkin-needed
The JS_IsArrayObject bug is bug 487674
Keywords: checkin-needed
Whiteboard: checkin-needed
Comment on attachment 371695 [details] [diff] [review] The patch [Checkin: Comment 15] http://hg.mozilla.org/mozilla-central/rev/40530e79373c
Attachment #371695 - Attachment description: The patch → The patch [Checkin: Comment 15]
(In reply to comment #2) > > http://lxr.mozilla.org/mozilla1.8/source/layout/xul/base/public/nsICanvasRenderingContext2D.idl > > That file needs to disappear, it's leftover droppings from an earlier misplaced > canvas impl. It was cvs removed on the trunk, but not on the branch. (It's > not even referenced in the makefile. You probably want the fix on branches and to do this removal too...
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Depends on: 493495
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: