The comment at talks about how we can rely on FileList being implemented as an XPCWN and so on, but they haven't been XPCWN in a while. Sadly, UnwrapReflectorToISupports() still works on Web IDL objects, so this codepath is still returning true for FileList. Does that mean we're doing unsafe things when mOptions->wrapReflectors is false? Should we just remove this FileList special-case? Something else?

Er, the comment at http://searchfox.org/mozilla-central/rev/db5e3a34d4b26f6c8e97fde4a16bf41f10f9b146/js/xpconnect/src/ExportHelpers.cpp#158-161

Nice catch - I think this is ok though. The impact of the bug is that we'll effectively always have the wrapReflectors=true behavior for FileList, which potentially means that somebody cloning an object graph containing a FileList might get have the error appear lazily (via a security wrapper denial when content tries to access the object) rather than eagerly (when the clone happens). In other words, security wrappers save us. So the safest thing is just to leave this be for the next two cycles and then remove the special case once XPCOM addons go away.

Do we have a tracking bug for things we can do post-57?

Bug 1347507?

I searched for at least 15 minutes and couldn't find bug 1347507. Thanks, Andrew!