workaround __exposedProps__ typed array issue in mozTCPSocket

RESOLVED FIXED in mozilla18

Status

()

defect
RESOLVED FIXED
7 years ago
5 months ago

People

(Reporter: asuth, Assigned: asuth)

Tracking

unspecified
mozilla18
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Bug 786639 makes mozTCPSocket's arraybuffer binary type support useless to content, but there is a simple workaround of creating the uint8array so that it lives in the content window's compartment.

Unit-test wise, this will be covered by the fix for bug 784893.
Attachment #656442 - Flags: review?(fabrice)
Attachment #656442 - Flags: review?(fabrice) → review+
Nice! Simple and logical fix.
https://hg.mozilla.org/mozilla-central/rev/b739aa9d9ede
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
The fix for bug 786639 has landed, so if this patch was backed out, things should still work.  But it actually seems like we may want to keep this fix since it is arguably more correct to have the typed array live in the content window's compartment from both a memory-usage tracking perspective (ex: about:memory) and for efficiency.

Donovan, does this seem reasonable?  And if so, is there anything more required than to update the comment?  In other words, is useWin as implemented okay, or should there be some cleanup?  I think constructors may actually work now, so it's also possible that book-keeping could just be simplified if/when that ever happens.
I think it's best to keep the useWin implementation as you did it in the patch. It seems slightly more "correct" to me, and more representative of the intent. The typedarrays are given to the content, so they should be owned by the content.

The about:memory thing alone is enough to make it worth it to leave this patch in, I think.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.