Preview URLs

• /en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities
• /en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts

(comment last updated: 2023-02-14 13:33:18)

... occasionally confuses extension developers

The use case is not about confusion:

// trap it once and fail forever after
const {setTimeout} = window;

// VS

// works because ... developers are confused?
const setTimeout = window.setTimeout.bind(window);

It is not possible to extract once like in any other JS env so it should be clarified why is that, imho.

... occasionally confuses extension developers

The use case is not about confusion:

// trap it once and fail forever after
const {setTimeout} = window;

// VS

// works because ... developers are confused?
const setTimeout = window.setTimeout.bind(window);

It is not possible to extract once like in any other JS env so it should be clarified why is that, imho.

This proves my point. window is commonly understood to refer to the global scope, but that is not the case. The standard way to get the global (including non-browser environments) is globalThis. Like this:

const setTimeout = globalThis.setTimeout.bind(globalThis);

There should be zero need to bind global utilities though + globalThis is not available to Firefox < 52, as mentioned in the bug. What are the benefits of having a window that doesn't act globally though, or just like globalThis? why is this addressed as "developers confusion" when it's a Firefox only thing? Anyway, we had implemented a workaround but the wording should be more on FF choice rather than developers confusion, imho.