David Baron :dbaron: Reporter
	Description • 19 years ago

From email:
=====
On Thursday 2005-10-13 22:53 -0500, Boris Zbarsky wrote:
> 1)  The designer of the gfxIImageFrame interface and of its implementation
> decided that following XPCOM rules for his methods was too much of a drag.
> So calling getImageData() from JS will crash or at least lead to reading of
> random memory by the image code after you've deallocated data it thinks it
> owns.  From C++ make sure to not delete the return value of getImageData()
> and you ought to be OK.

Is there a bug on this?  They should at least be marked [noscript], if
not [shared] or whatever.
=====

We should put correct IDL notations on this interface so that it either can't be used from script or (better) script could understand the strange things it does.

	Stuart Parmenter Assignee
	Comment 1 • 19 years ago

Yes, following the XPCOM rules there is a drag as it means copying huge amounts of data every time it is called.

It should probably be marked as [shared].

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 18 years ago

You want that annotation on the out param, not on the method.

	Justin Dolske [:Dolske]
	Comment 5 • 17 years ago

Hmm, this appears to be not so simple...

void getImageData([shared, array, size_is(length)] out PRUint8 bits, out unsigned long length);

results in:

mozilla/gfx/idl/gfxIImageFrame.idl:132: Error: [shared] parameter "bits" cannot be of array type

	JP Rosevear [:jpr]
	Comment 6 • 13 years ago

This IDL ultimately got replaced with imgIContainer.  Most functions in there are now marked [noscript] (no direct equivalent now).