Fix inclusion of jsobj.h in Content code due to ArrayBuffer optimizations




JavaScript Engine
6 years ago
6 years ago


(Reporter: nsm, Assigned: nsm)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed-in-tracemonkey)


(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: 

Since ArrayBuffer was collapsed into a JSObject by bug 656519, content and DOM code which used it required the inclusion of jsobj.h, which is frowned upon :)

This patch creates two versions of the public API for ArrayBuffer, JS_GetArrayBufferByteLength and JS_GetArrayBufferData which are not-inline and can be used treating JSObject as opaque, while js_GetArrayBufferByteLength and js_GetArrayBufferData are used by the engine.

Reproducible: Always
Depends on: 656519
Created attachment 539672 [details] [diff] [review]
API fix
Comment on attachment 539672 [details] [diff] [review]
API fix

My only thought is that you could let the inlined versions still be member functions on ArrayBuffer (and let them simply be undefined for consumers outside the engine) and simply defined in jstypedarrayinlines.h. Do you have feelings one way or the other?
Attachment #539672 - Flags: review+


6 years ago
Ever confirmed: true
I put them as functions for consistency. Both private and public have the same name except for js/JS.

Comment 4

6 years ago
> My only thought is that you could let the inlined versions still be member
> functions on ArrayBuffer

Fwiw, this was my assumption about how we'd do it.
Created attachment 539834 [details] [diff] [review]
API fix

Inline implementation is kept part of the class.
Attachment #539672 - Attachment is obsolete: true
Yeah, the consistency is a hold-over from the pre-C++ days of SpiderMonkey. We're migrating more and more towards class methods over js_* methods.
Assignee: general → nsm.nikhil

I didn't add the bug # to the checkin message, sadly :-/.


6 years ago
Whiteboard: fixed-in-tracemonkey

Comment 8

6 years ago
Back it out and reland with the bug#?

Comment 9

6 years ago
But it's not clear why that wasn't there to start with.... <-- backout <-- relanding

Nikhil, in general, when you write your commit messages for patches, please include the bug # in the commit message. It make it easier when doing hg archaeology to tie specific commits to bugs.
cdleary-bot mozilla-central merge info: (backout)
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.