On Thu, Aug 31, 2017 at 11:14 AM, Kris Maglione <kmagli...@mozilla.com> wrote:
> A quick heads-up on some incoming changes to the JS component loader that > may affect some existing JSM or JS component code: > > 1) As of bug 1394556[1], all JS module and component scripts are > automatically compiled in strict mode[2]. While I fixed all of the > resulting issues that showed up in automated tests, new issues may turn up > in code with incomplete test coverage. Please be on the lookout for errors > like "TypeError: this is null", "TypeError: setting a property that has > only a getter", and "ReferenceError: assignment to undeclared variable", > and if you see any, file bugs blocking bug 1394556. > > 2) Andrew McCreight has been working on changing the component loader to > load most modules and components into a single global[3], with each module > still getting its own top-level variable scope (similar to a with() block). > Most of the blockers for this have been resolved, and it should hopefully > be ready to land within the next week. > > This change will significantly reduce the memory overhead of JS modules, > along with the performance overhead of creating dozens module globals at > startup, and of creating thousands of cross-compartment object wrappers at > runtime. > But it does so at the cost of decreased isolation among module scripts. > All (non-add-on) modules will now share prototypes for built-in objects. It > will be possible to define objects on the shared global that affect all > modules. getGlobalForObject will no longer return the root scope for a > module. In short, it's possible we will see subtle issues as a result of > this change (as we often saw on b2g, which its module loader differed from > the desktop module loader), so please be on the look-out over the next few > weeks. > This has now landed on autoland, as part of bug 1381961. Here are some notes on what to expect, written by Ted Campbell and Kris Maglione: Notes to JSM Authors Your global vars, lets, consts, and |this| will now belong to a scope within a shared JS global. JSMs will behave 99% unchanged. The |(1,eval)(...)| and |new Function(...)| patterns now run in the context of the shared global and are thus DEPRECATED. In future it is likely that CSP will be used to deny all eval/Function usage. The shared global namespace will become become polluted by Cu.importGlobalProperties and WebIDL classes. If you need one of these names, assume it isn't available and continue to load it normally. If you define a variable in your JSM with the same name, yours will cover and so you shouldn't worry. Functions such as Cu.getGlobalForObject(...) will return the shared global and should primarily only be used for compartment-related matters. In the devtools debugger, you may see a scope labelled |NonSyntacticVariablesObject|. This is the per-JSM environment and the BackstagePass is the shared global. There is an environment variable MOZ_LOADER_SHARE_GLOBAL=0/1 to control enable/disable shared global support. This can be useful in certain testing scenarios. The jsloader.shareGlobal pref exists in about:config as well and only takes effect on restart. You now share prototypes and constructors for built-in objects like Object, Array, Function, ... with all other system JSMs. They don't belong solely to you anymore. Do not add properties to them, or modify them in any other way. Beware using the subscript loader to load scripts into objects from other JSMs. They'll be executed in the context of your pseudo-global scope. Also beware of creating wrappers around the subscript loader that take a non-global scope object, for the same reason. Their scopes will be determined by the location of the loadSubScript call. > > Thanks. > > -Kris > > [1]: https://bugzil.la/1394556 > [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe > rence/Strict_mode > [3]: https://bugzil.la/1186409 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
