javascript-Firefox引导扩展：命名空间

我正在研究自举扩展.看看其中一些扩展的代码,我看到了很多变量,常量和函数声明.

它们都在window对象中声明了吗？
命名空间污染/冲突是否存在问题？

我将每件事都包装在我完成的覆盖扩展中的一个对象/命名空间中.
自举扩展在这方面是否有所不同？

我注意到所有的bootstrapped.js都使用相同/标准的函数名.这是否意味着自举扩展名已被沙盒化或封闭了其范围？

解决方法:

bootstrap.js范围

Are they all declared in window object? Isn’t there an issue with namespace pollution/clash?

…

I have noticed that all bootstrapped.js use the same/standard function names. Does that mean that bootstrapped extensions are sandboxed or their scope enclosed?

为了扩展@paa注释：bootstrap.js确实确实拥有它自己的作用域.

AddonManager将为每个bootstrap.js创建一个新的作用域(如果需要,也可以创建“命名空间”).现在,该实现使用Components.utils.Sandbox,但这是一个实现细节.

这意味着没有窗口对象. bootstrap.js将在每个Firefox进程中加载​​一次,并且没有窗口对象.这与覆盖脚本非常不同,覆盖脚本将在每个新窗口中加载一次,并与Firefox代码和其他加载项的覆盖脚本共享一个共同的作用域(窗口对象本身).

这也意味着自举插件可以自由选择范围内的任何名称(他们的个人沙盒),而不必担心与其他插件发生冲突,只要这些名称在Javascript中通常是有效的即可.

唯一的例外是

>附加功能必须实现附加功能管理器将调用的附加功能的入口点功能名称,因此具有特殊含义(启动,关闭,安装,卸载),
>沙箱随附的预定义内容(组件和Javascript内置对象,如对象,字符串,数组,映射等)
> AddonManager将注入的内容(例如__SCRIPT_URI_SPEC __,ADDON _ *,APP_ *常量).

自Firefox 30起的预定义名称的完整列表：

Components.utils.reportError(Object.getOwnPropertyNames(this).join(", "));

// Object, Function, eval, Components, XPCNativeWrapper, dump, debug,
// importFunction, IDBCursor, IDBCursorWithValue, EventTarget, IDBDatabase,
// IDBFactory, FileHandle, IDBFileHandle, IDBIndex, IDBKeyRange,
// IDBObjectStore, IDBRequest, IDBOpenDBRequest, IDBTransaction, Event,
// IDBVersionChangeEvent, indexedDB, APP_STARTUP, APP_SHUTDOWN, ADDON_ENABLE,
// ADDON_DISABLE, ADDON_INSTALL, ADDON_UNINSTALL, ADDON_UPGRADE,
// ADDON_DOWNGRADE, Worker, ChromeWorker, __SCRIPT_URI_SPEC__, undefined,
// Array, Boolean, JSON, Date, Math, isNaN, isFinite, parseFloat, parseInt,
// NaN, Infinity, Number, String, escape, unescape, uneval, decodeURI,
// encodeURI, decodeURIComponent, encodeURIComponent, RegExp, Error,
// InternalError, EvalError, RangeError, ReferenceError, SyntaxError,
// TypeError, URIError, Iterator, StopIteration, Int8Array, Uint8Array,
// Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array,
// Float64Array, Uint8ClampedArray, DataView, ArrayBuffer, Proxy, WeakMap,
// Map, Set, Intl

操纵其他范围

但是,自举加载项仍然需要考虑周全,并避免在与其他作用域(例如Windows,JS代码模块,其他加载项引导作用域)进行交互时发生冲突.操纵其他范围也可能导致附加自举范围泄漏.

例如.

Cu.import("resource://gre/modules/Services.jsm");
Services.foo = "bar";

这会将foo属性添加到位于共享Services.jsm代码模块中的Services对象.
所有其他加载项和浏览器代码也将看到Services.foo,因此可能会导致冲突,并且常规操作不会污染共享名称空间规则的适用性.

另外,当您的附加组件关闭时,您必须再次删除Services.foo,否则Services.jsm范围将保留对其的引用,并且由于foo的值(字符串“ bar”)位于您的引导程序中隔离区,由于该引用,它将使您的引导隔离区保持活动状态,并有效地导致内存泄漏(在mozilla slang中称为Zombie compartments).

要么

// Get the most recent browser window
var browserWindow = Services.wm.getMostRecentWindow("navigator:browser");
browserWindow.doSomething = function() {
  browserWindow.alert("hello world");
};

这等效于具有以下内容的覆盖脚本：

function doSomething() {
  alert("hello world");
}

两者都会在浏览器窗口范围内添加新名称doSomething,因此该名称可能会与其他加载项冲突,并且不会污染共享名称空间规则的适用性.
同样,这可能以与上一个示例相同的方式泄漏,因此自举加载项将不得不在关机时再次删除该属性以避免这种情况.

标签：firefox,firefox-addon,javascript,firefox-addon-restartless
来源： https://codeday.me/bug/20191121/2052826.html