Fixed incorrect handling of integer jsid to access dataset properties. Converted integer jsids to strings. Added checks to ensure jsids are strings when using them as strings. r=sicking
Note that there is one key difference between this implementation and the spec. In this patch MozBlobBuilder.getBlob("content/type"); returns a Blob and clears the MozBlobBuilder. In the spec the BlobBuilder is not cleared. Thus,
let bb = new MozBlobBuilder();
MozBlobBuilder.append("foo");
let blob1 = MozBlobBuilder.getBlob("content/type");
// blob1 contains "foo"
MozBlobBuilder.append("bar");
let blob2 = MozBlobBuilder.getBlob("content/type");
// blob2 contains "bar", the spec says it should contain "foobar".
IMO, the spec behavior optimizes for the wrong case. BlobBuilder will probably be used mostly as a one-shot API. Additionally, the spec requires the BlobBuilder to hang on to potentially large amounts of memory between the getBlob() call and when the BlobBuilder is GCd.
These issues have been raised on the listserv.
This crash was occurring when no program is bound and the uniform object isn't bound to a program either. The fix is to properly check if a program is bound.
This is needed to correctly handle exceeding large canvases. The previous patch lets us know that the canvas is too large, and this canvas then correctly marks it as 'bad' so that we no longer crash.
We thought it was only crashy with NVIDIA, but it's now confirmed on ATI on Mac OS 10.6.7 too
It's OK to just not call it, as it's only a developer feature and not really useful in actual content.
Note that there is one key difference between this implementation and the spec. In this patch mozBlobBuilder.getBlob("content/type"); returns a Blob and clears the mozBlobBuilder. In the spec the BlobBuilder is not cleared. Thus,
let bb = new mozBlobBuilder();
mozBlobBuilder.append("foo");
let blob1 = mozBlobBuilder.getBlob("content/type");
// blob1 contains "foo"
mozBlobBuilder.append("bar");
let blob2 = mozBlobBuilder.getBlob("content/type");
// blob2 contains "bar", the spec says it should contain "foobar".
IMO, the spec behavior optimizes for the wrong case. BlobBuilder will probably be used mostly as a one-shot API. Additionally, the spec requires the BlobBuilder to hang on to potentially large amounts of memory between the getBlob() call and when the BlobBuilder is GCd.
These issues have been raised on the listserv.
