"Exotic" objects for DOM collections

[rxdevebeo]

The Boa engine doesn't allow external crates to create "exotic" objects. This mechanism is locked down (pub(crate)) and is only accessible within the engine itself. Without it, it's impossible to build a DOM on top of Boa: DOM collections like NodeList or HTMLCollection require indexed and named properties. Proxy isn't a good fit.

So, the goal is to add a narrow, optional API (a feature flag, disabled by default) that allows the host to override only property-related methods: get, set, delete, key enumeration, and the like, while keeping all the truly dangerous methods out of reach: no changes to function calls/constructors, prototypes, or extensibility, no exposure of the internal structure of objects.

P.S. My English isn't very good, sorry.

[jedel1043]

What about JsProxy and JsProxyBuilder? https://docs.rs/boa_engine/latest/boa_engine/object/builtins/struct.JsProxyBuilder.html

They're currently mirroring the method signature of Proxy, but it's slightly unergonomic since Rust code needs to do all the casting between JsValue and the internal methods. Would modifying that API to be more "Rust native" be enough to cover your requirements?

JsProxy is ideal API-wise, since it exposes the internal methods in a "stable" fashion, while giving the flexibility of modifying the internal methods in the future.

[rxdevebeo]

I've already looked at JsProxyBuilder before writing this. But it will still return an exotic Proxy object with [[ProxyTarget]]/[[ProxyHandler]], only with native interception functions instead of a JavaScript handler object.

This is still the Proxy, not the target, so the host still has to unwrap the wrapper on every call instead of downcast_ref on the receiver. And the [[GetOwnProperty]]/[[OwnPropertyKeys]] in the proxy object must still remain consistent with the target object. The blocking issue is the object structure itself.

[jedel1043]

I don't think that's unsolvable from the API side though? We could have a generic JsProxy<T> then make all hooks receive JsObject<JsProxy<T>> as the target, and automatically cast to that before calling the hook

[rxdevebeo]

This could indeed solve the problem, but it depends on one undefined point: does JsProxy store a separate target object, or does T reside directly on the object on which the script calls methods?

Do [[OwnPropertyKeys]]/[[GetOwnProperty]] in JsProxy still perform target consistency invariant checks, or does this variant skip them?

[jedel1043]

does JsProxy store a separate target object, or does T reside directly on the object on which the script calls methods?

I would think JsProxy would be defined as an equivalent to JsProxy<T>(JsObject<T>), and we would add the proxy handlers either at runtime or at const time; we need to explore and design the API shape basically, depending on your requirements.

Do [[OwnPropertyKeys]]/[[GetOwnProperty]] in JsProxy still perform target consistency invariant checks, or does this variant skip them?

We currently do dynamic type checking to run the internal methods, but that also applies to all other exotic objects that require getting internal data from the object. There's a plan to remove those checks in the future, but we haven't got to implement that.

[rxdevebeo]

Using JsProxy<T>(JsObject<T>) as a newtype is precisely the solution that allows me to bypass the brand check issue: since there is no separate target object, when a method is called via a property access, this already has the type JsObject<T>. Is this already being implemented as part of a task, or does a solution need to be prepared?

My question is actually slightly different. In the absence of a separate target object, what exactly will this invariant-checking algorithm compare the trap result against? If the answer is "nothing - there is no second object for comparison," then that works for me.

[jedel1043]

Using JsProxy(JsObject) as a newtype is precisely the solution that allows me to bypass the brand check issue: since there is no separate target object, when a method is called via a property access, this already has the type JsObject. Is this already being implemented as part of a task, or does a solution need to be prepared?

This is not how currently the internal methods work. They all receive an erased JsObject and you need to manually cast to JsObject<T> inside the method. There are no tasks to implement this, just something we thought it would be nice to have but not a priority.

My question is actually slightly different. In the absence of a separate target object, what exactly will this invariant-checking algorithm compare the trap result against? If the answer is "nothing - there is no second object for comparison," then that works for me.

There is no "invariant-checking" algorithm. The API I'm thinking of is to just call JsObject::downcast before calling the defined proxy methods so that they can take JsObject<T> instead of JsObject.

[rxdevebeo]

Does this mechanism utilize the actual exotic Proxy object from the boa_engine::builtins::proxy module? Or is it a completely independent exotic object mechanism that simply has the type JsProxy<T>?
Would you consider such a PR from me if I were to submit one? And is there a preferred name for this entity, if not JsProxy?

[jedel1043]

It would have to be something different than Proxy, since we want to have something that is Rust-native instead of JS-native. Honestly calling it JsNativeProxy might be better to differentiate the "Rust proxy traps" case from the "JS proxy traps" case.

[HomeRobot]

I would propose the following solution.

use crate::{
    Context, JsResult, JsValue,
    object::{
        JsObject, NativeObject,
        internal_methods::{
            InternalMethodPropertyContext, InternalObjectMethods, ORDINARY_INTERNAL_METHODS,
            ordinary_define_own_property, ordinary_delete, ordinary_get,
            ordinary_get_own_property, ordinary_has_property, ordinary_own_property_keys,
            ordinary_set,
        },
    },
    property::{PropertyDescriptor, PropertyKey},
};

pub trait JsNativeProxyHooks: NativeObject + Sized {
    fn get_own_property(
        this: &JsObject<Self>,
        key: &PropertyKey,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<Option<PropertyDescriptor>> {
        ordinary_get_own_property(&this.clone().upcast(), key, context)
    }

    fn define_own_property(
        this: &JsObject<Self>,
        key: &PropertyKey,
        desc: PropertyDescriptor,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        ordinary_define_own_property(&this.clone().upcast(), key, desc, context)
    }

    fn has_property(
        this: &JsObject<Self>,
        key: &PropertyKey,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        ordinary_has_property(&this.clone().upcast(), key, context)
    }

    fn get(
        this: &JsObject<Self>,
        key: &PropertyKey,
        receiver: JsValue,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<JsValue> {
        ordinary_get(&this.clone().upcast(), key, receiver, context)
    }

    fn set(
        this: &JsObject<Self>,
        key: PropertyKey,
        value: JsValue,
        receiver: JsValue,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        ordinary_set(&this.clone().upcast(), key, value, receiver, context)
    }

    fn delete(
        this: &JsObject<Self>,
        key: &PropertyKey,
        context: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        ordinary_delete(&this.clone().upcast(), key, context)
    }

    fn own_property_keys(
        this: &JsObject<Self>,
        context: &mut Context,
    ) -> JsResult<Vec<PropertyKey>> {
        ordinary_own_property_keys(&this.clone().upcast(), context)
    }
}

mod shim {
    use super::*;

    #[inline]
    fn typed<T: NativeObject>(obj: &JsObject) -> JsObject<T> {
        obj.clone().downcast::<T>().unwrap_or_else(|_| {
            unreachable!("native-proxy shim dispatched under the wrong T — \
                          this table is only ever installed as T's own vtable")
        })
    }

    pub(super) fn get_own_property<T: JsNativeProxyHooks>(
        obj: &JsObject, key: &PropertyKey, ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<Option<PropertyDescriptor>> {
        T::get_own_property(&typed::<T>(obj), key, ctx)
    }
    pub(super) fn define_own_property<T: JsNativeProxyHooks>(
        obj: &JsObject, key: &PropertyKey, desc: PropertyDescriptor,
        ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        T::define_own_property(&typed::<T>(obj), key, desc, ctx)
    }
    pub(super) fn has_property<T: JsNativeProxyHooks>(
        obj: &JsObject, key: &PropertyKey, ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        T::has_property(&typed::<T>(obj), key, ctx)
    }
    pub(super) fn get<T: JsNativeProxyHooks>(
        obj: &JsObject, key: &PropertyKey, receiver: JsValue,
        ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<JsValue> {
        T::get(&typed::<T>(obj), key, receiver, ctx)
    }
    pub(super) fn set<T: JsNativeProxyHooks>(
        obj: &JsObject, key: PropertyKey, value: JsValue, receiver: JsValue,
        ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        T::set(&typed::<T>(obj), key, value, receiver, ctx)
    }
    pub(super) fn delete<T: JsNativeProxyHooks>(
        obj: &JsObject, key: &PropertyKey, ctx: &mut InternalMethodPropertyContext<'_>,
    ) -> JsResult<bool> {
        T::delete(&typed::<T>(obj), key, ctx)
    }
    pub(super) fn own_property_keys<T: JsNativeProxyHooks>(
        obj: &JsObject, ctx: &mut Context,
    ) -> JsResult<Vec<PropertyKey>> {
        T::own_property_keys(&typed::<T>(obj), ctx)
    }
}

pub const fn native_proxy_methods<T: JsNativeProxyHooks>() -> InternalObjectMethods {
    InternalObjectMethods {
        __get_own_property__: shim::get_own_property::<T>,
        __define_own_property__: shim::define_own_property::<T>,
        __has_property__: shim::has_property::<T>,
        __get__: shim::get::<T>,
        __set__: shim::set::<T>,
        __delete__: shim::delete::<T>,
        __own_property_keys__: shim::own_property_keys::<T>,
        ..ORDINARY_INTERNAL_METHODS
    }
}