Skip to content

[browser] JSObject.GetPropertyAsJSObject on prototypes is not consistent #110716

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.

Sign up for GitHub

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

Jump to bottom
Closed
miroljub1995 opened this issue Dec 15, 2024 · 6 comments · Fixed by #115773
Closed

[browser] JSObject.GetPropertyAsJSObject on prototypes is not consistent #110716

miroljub1995 opened this issue Dec 15, 2024 · 6 comments · Fixed by #115773
Assignees
@pavelsavara
Labels
arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript os-browser Browser variant of arch-wasm
Milestone
10.0.0

Comments

@miroljub1995
Copy link

Description

In dotnet new wasmbrowser template I have really weird situation with JSObject.GetPropertyAsJSObject where the order of calls makes different output.

When I execute JSHost.GlobalThis.GetPropertyAsJSObject("Window") alone, it works great, but if I execute it after I execute JSHost.GlobalThis.GetPropertyAsJSObject("EventTarget"), looks like it returns the EventTarget instead of Window.

Reproduction Steps

Here is a minimal change to template. Just replace Program.cs with the following:

using System.Runtime.InteropServices.JavaScript;

public partial class MyClass
{
    public static void Main()
    {
    }

    [JSExport]
    internal static string Greeting()
    {
        var temp1 = JSHost.GlobalThis.GetPropertyAsJSObject("EventTarget");
        var temp2 = JSHost.GlobalThis.GetPropertyAsJSObject("Window");

        return $"Hello from Greeting, it should return False: but got {temp1 == temp2}";
    }
}

With this output it prints ...got True, but if we flip the variables temp1 and temp2, like the following, it prints ...got False:

using System.Runtime.InteropServices.JavaScript;

public partial class MyClass
{
    public static void Main()
    {
    }

    [JSExport]
    internal static string Greeting()
    {
        var temp2 = JSHost.GlobalThis.GetPropertyAsJSObject("Window");
        var temp1 = JSHost.GlobalThis.GetPropertyAsJSObject("EventTarget");

        return $"Hello from Greeting, it should return False: but got {temp1 == temp2}";
    }
}

Expected behavior

It should write ...got False in both cases.

Actual behavior

When JSHost.GlobalThis.GetPropertyAsJSObject("EventTarget") is executed before JSHost.GlobalThis.GetPropertyAsJSObject("Window"), JSHost.GlobalThis.GetPropertyAsJSObject("Window") returns EventTarget instead of Window constructor.

Regression?

No response

Known Workarounds

No response

Configuration

dotnet --info output:

.NET SDK:
 Version:           9.0.101
 Commit:            f303476b53
 Workload version:  9.0.101
 MSBuild version:   17.12.12+f303476b5

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  15.1
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /opt/homebrew/Cellar/dotnet/9.0.101/libexec/sdk/9.0.101/

.NET workloads installed:
 [wasm-tools]
   Installation Source: SDK 9.0.100
   Manifest Version:    9.0.0/9.0.100
   Manifest Path:       /Users/<My User>/.dotnet/sdk-manifests/9.0.100/microsoft.net.workload.mono.toolchain.current/9.0.0/WorkloadManifest.json
   Install Type:        FileBased

Configured to use workload sets when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: arm64
  Commit:       f303476b53

.NET SDKs installed:
  9.0.101 [/opt/homebrew/Cellar/dotnet/9.0.101/libexec/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0 [/opt/homebrew/Cellar/dotnet/9.0.101/libexec/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0 [/opt/homebrew/Cellar/dotnet/9.0.101/libexec/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/opt/homebrew/Cellar/dotnet/9.0.101/libexec]

global.json file:
  Not found

Browser Chrome Version 131.0.6778.140 (Official Build) (arm64)

Other information

No response
@ghost ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Dec 15, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Dec 15, 2024
@vcsjones vcsjones added area-System.Runtime.InteropServices.JavaScript and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Dec 15, 2024
@maraf maraf added arch-wasm WebAssembly architecture os-browser Browser variant of arch-wasm labels Apr 8, 2025
@maraf maraf added this to the 10.0.0 milestone Apr 8, 2025
@maraf maraf removed the untriaged New issue has not been triaged by the area owner label Apr 8, 2025
@dotnet-policy-service Dotnet Policy Service
Copy link
Contributor

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

@maraf
Copy link
Member

maraf commented Apr 8, 2025

cc @pavelsavara

@pavelsavara pavelsavara self-assigned this Apr 8, 2025
@pavelsavara
Copy link
Member

This is because Window prototype is inherited from EventTarget prototype.

Try

EventTarget["test"]=1
console.log(Window["test"])

We are setting js_handle into marshaled objects in order to keep the identity.

runtime/src/mono/browser/runtime/gc-handles.ts

Lines 83 to 85 in b6a8764

if (Object.isExtensible(js_obj)) {
js_obj[cs_owned_js_handle_symbol] = js_handle;
}

@pavelsavara
Copy link
Member

Maybe we should not cache the js_handle into prototypes.

@maraf thoughts ?

@pavelsavara
Copy link
Member

@miroljub1995 why are you marshaling those prototypes ? What's the use-case ?

@pavelsavara pavelsavara changed the title JSObject.GetPropertyAsJSObject is not consistent [browser] JSObject.GetPropertyAsJSObject on prototypes is not consistent May 20, 2025
@pavelsavara pavelsavara mentioned this issue May 20, 2025
Merged
@miroljub1995
Copy link
Author

miroljub1995 commented May 20, 2025 •
edited
Loading

I started to build some library that holds reference of constructors and noticed this issue after 24 hours of debugging the problem 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pavelsavara pavelsavara

Labels
arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript os-browser Browser variant of arch-wasm
Projects
None yet
Milestone
10.0.0
Development

Successfully merging a pull request may close this issue.

[browser] don't set js_handle for js prototypes pavelsavara/runtime
4 participants
@pavelsavara @vcsjones @maraf @miroljub1995