Skip to content

Add dummy PerformanceObserver #795

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

karlseguin
Copy link
Collaborator

Adds a dummy PerformanceObserver. Only the supportedEntryTypes static attribute is supported, and it currently returns an empty array. This hopefully prevents code from trying to use it. For example, before using it, reddit checks if specific types are supported and, if not, doesn't use it.

This introduced complexity in the js runtime. Our current approach to attributes only works with primitive types. Non-primitive types can't be attached to a FunctionTemplate (v8 will crash saying only primitive types can be set). Plus, all non primitive types require a context to create anyways.

We now detect "primitive" attributes and "complex" attributes. Primitive attributes are setup as before. Complex attributes are setup per-context, requiring another loop through our types to detect & setup on each context creation.

Adds a dummy PerformanceObserver. Only the supportedEntryTypes static attribute
is supported, and it currently returns an empty array. This hopefully prevents
code from trying to use it. For example, before using it, reddit checks if
specific types are supported and, if not, doesn't use it.

This introduced complexity in the js runtime. Our current approach to
attributes only works with primitive types. Non-primitive types can't be
attached to a FunctionTemplate (v8 will crash saying only primitive types can
be set). Plus, all non primitive types require a context to create anyways.

We now detect "primitive" attributes and "complex" attributes. Primitive
attributes are setup as before. Complex attributes are setup per-context,
requiring another loop through our types to detect & setup on each context
creation.

// https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver
pub const PerformanceObserver = struct {
pub const _supportedEntryTypes = [0][]const u8{};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the need to register the Array as a type be resolved if we handle static properties the same as instance properties, like get_x()?
It would just return statis data instead of instance data.
I think we can do static_supportedEntryTypes() can we not?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arrays are already supported. This code goes through the existing zigValueToJs. The issue is that they're only supported when we have a context. You're effectively doing new Array(); - you need a handlescope + context to be able to do that.

We have simpleZigValueToJs (which could be renamed to "primitive" now that I know that's what V8 calls them) which specifically exists for cases where we don't have a context, but need a JS value.

static_ creates a function - it needs to be invoked with ()in JS, else you get a function reference, not the value. We could do static_get_, but I think I might still implement it the same way (directly against the JSObject) because I think it'll perform better than invoking a function callback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants