383566 - Imported module objects can have their properties reset

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Alex Vincent [:WeirdAl]]

Attachment: test JS file

I just realized that objects imported from JSM files could have their properties changed.  This is probably a Bad Thing, as it means what one import relies on, another import could break.

Steps to reproduce:
(1) Drop the attached file into js/src/xpconnect/tests/unit/bogus_component.js.
(2) Add the following line to js/src/xpconnect/tests/unit/test_import.js, before the component_import.js file is loaded:

do_load_module("/js/src/xpconnect/tests/unit/bogus_component.js");

(3) In the objdir, make -C js/src/xpconnect
(4) In the objdir, make -C js/src/xpconnect check

Expected results:  Test passes.
Actual results:
JS Component Loader: ERROR file:///home/ajvincent/trunk/mozilla/js/src/xpconnect/tests/unit/component_import.js:127
                     TypeError: XPCOMUtils.generateNSGetModule is not a function
[Exception... "Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]"  nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)"  location: "JS frame :: ../../../../_tests/xpcshell-simple/TestXPC/unit/test_import.js :: run_test :: line 78"  data: no]
*** FAIL ***

Comment 1

[Nickolay_Ponomarev]

I think it's actually a feature. Using import(), one can easily create a shared scope without having to create a component and using wrappedJSObject tricks.

I see your point though, so perhaps the module should be able to specify whether it wants its scope to be writable by other code or no.

Comment 2

[Jeff Walden [:Waldo]]

I don't particularly think this is a bug; I think it's reasonable to expect
that JS code that imports modules will play nice.  This could be done, however,
using JS_SealObject, but if you did it, you'd also prevent the module itself
from changing any of the properties of each imported symbol.  The component
could get around this by storing this mutable state in non-exported objects,
but that's a bit painful.

I recommend WONTFIX.  If you want to use JS modules, you should play nice with
them.

Comment 3

[Alex Vincent [:WeirdAl]]

jwalden, I disagree - the module itself could also store mutable state in non-exported objects.  It's like how JS components can have private objects in the same scope, and the IDL file defines access points into the component's public methods.  The primary difference would be that private properties couldn't be stored on the module's exported objects - and that's easily worked around inside the module by having a private wrapper object.

Comment 4

[Robert Sayre]

ES5 will let developers solve this.