Bug 965898 - Implement an Xray subclass that we can use to implement HTML5 cross-origin semantics. r=gabor

js/xpconnect/wrappers/FilteringWrapper.cpp

@@ -170,7 +170,15 @@ FilteringWrapper<Base, Policy>::enter(JSContext *cx, HandleObject wrapper,
     return true;
 }
 
-#define XOW FilteringWrapper<SecurityXrayDOM, CrossOriginAccessiblePropertiesOnly>
+CrossOriginXrayWrapper::CrossOriginXrayWrapper(unsigned flags) : SecurityXrayDOM(flags)
+{
+}
+
+CrossOriginXrayWrapper::~CrossOriginXrayWrapper()
+{
+}
+
+#define XOW FilteringWrapper<CrossOriginXrayWrapper, CrossOriginAccessiblePropertiesOnly>
 #define NNXOW FilteringWrapper<CrossCompartmentSecurityWrapper, Opaque>
 #define NNXOWC FilteringWrapper<CrossCompartmentSecurityWrapper, OpaqueWithCall>
 

js/xpconnect/wrappers/FilteringWrapper.h

@@ -51,6 +51,17 @@ class FilteringWrapper : public Base {
     static const FilteringWrapper singleton;
 };
 
+/*
+ * The HTML5 spec mandates very particular object behavior for cross-origin DOM
+ * objects (Window and Location), some of which runs contrary to the way that
+ * other XrayWrappers behave. We use this class to implement those semantics.
+ */
+class CrossOriginXrayWrapper : public SecurityXrayDOM {
+  public:
+    CrossOriginXrayWrapper(unsigned flags);
+    virtual ~CrossOriginXrayWrapper();
+};
+
 }
 
 #endif /* __FilteringWrapper_h__ */

js/xpconnect/wrappers/WrapperFactory.cpp

@@ -398,7 +398,7 @@ SelectWrapper(bool securityWrapper, bool wantXrays, XrayType xrayType,
 
     // This is a security wrapper. Use the security versions and filter.
     if (xrayType == XrayForDOMObject)
-        return &FilteringWrapper<SecurityXrayDOM,
+        return &FilteringWrapper<CrossOriginXrayWrapper,
                                  CrossOriginAccessiblePropertiesOnly>::singleton;
 
     // There's never any reason to expose other objects to non-subsuming actors.