Object assign does not appear to work for NativeArray

[rmmasse40]

The problem looks to be with the AbstractEcmaObjectOperations put method. It uses the ScripttableObject putImpl method which ignores the dense implementation, using the slotMap instead.

[aardvark179]

I think this was fixed in d243106 last December. Could you either check using a build on master, or provide an explicit test case and the exact version you're using?

[rmmasse40]

My original submission was on 1.7.15 which is when we noticed the issue. I have updated to version 1.8.0 (which includes the commit) and still seeing the issue.
Here is a quick test case:

let src = [1,2,4];
let tgt = [4,5,7];
Object.assign(tgt, src);
tgt;

"tgt" result shows as [4,5,7]. i.e. unchanged rather than expected [1,2,4]

[aardvark179]

Ah yes. I see it is still not doing quite the right thing. I will investigate more when less jet lagged.

[aardvark179]

Okay, I have a fix, and I’ll make a PR. This whole area is a little finicky because all of Rhino’s property access methods almost map to those in the spec, but not quite perfectly. Also there appears to be nothing in test262 for this particular combination. I should probably check if there are any other exotic object types they are missing.

I think they wrote tests for all object types with special [[Set]] implementations, but ignored the fact that ordinary objects delegate to [[DefineOwnProperty]] and so you also need tests for object types with special versions of that.

[aardvark179]

@gbrail the implementation of this whole area is slightly off because put doesn't return a boolean, but in the spec [[Set]] does. If we're changing method signatures as part of separating out scopes from scriptable objects should we take the opportunity to fix that, and then we could start to tidy up this whole area?

[rbri]

@aardvark179 the same for delete - there is also the return code missing. This is a real problem in some areas. Do you have a backward compatible solution in mind?

[aardvark179]

@aardvark179 the same for delete - there is also the return code missing. This is a real problem in some areas. Do you have a backward compatible solution in mind?

I don't have a backward compatible solution in mind, I tried when prototyping separating scopes and scriptable objects we have too many cases where our uses of super.put() and similar resulted in very hard to debug errors.

But… since introducing scopes will be a breaking change (though hopefully a very easy one for people to fix, and detectable at compile time) then maybe we should make the return type change at the same time?

[gbrail]

FWIW I am beginning to think that it will be OK to make these kind of changes and even call it Rhino 2.0.0 if we want. But the trick is to know exactly what they are and have a doc ready to go that explains to people how to make the changes. +1 if we can write an AGENTS.md or similar so that users can tell their LLM how to fix their code too. This problem (return codes from put and delete) is one of the oldest and most intractable in the codebase I think.

…

On Wed, Oct 22, 2025 at 10:32 AM Duncan MacGregor ***@***.***> wrote: *aardvark179* left a comment (mozilla/rhino#2126) <#2126 (comment)> @aardvark179 <https://github.com/aardvark179> the same for delete - there is also the return code missing. This is a real problem in some areas. Do you have a backward compatible solution in mind? I don't have a backward compatible solution in mind, I tried when prototyping separating scopes and scriptable objects we have too many cases where our uses of super.put() and similar resulted in very hard to debug errors. But… since introducing scopes will be a breaking change (though hopefully a very easy one for people to fix, and detectable at compile time) then maybe we should make the return type change at the same time? — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I24W67MI5FOC3RWA7S33Y6IPNAVCNFSM6AAAAACJLRL7ZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZSGY3TMOJRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aardvark179]

Okay, I’ll add that to the method signature changes in my scopes branch and see what it helps shake out.