Bugzilla

I did double-check how Services is imported or lazily imported in all other API modules which are part of Firefox and we do have all these three variations:

- [`var { Services } = ChromeUtils.import(...)`](https://searchfox.org/mozilla-central/search?q=var+%7B+Services+%7D+%3D+ChromeUtils.import%28&path=ext-*.js)
- [`ChromeUtils.defineModuleGetter(...`](https://searchfox.org/mozilla-central/rev/2b99ea2e97eef00a8a1c7e24e5fe51ab5304bc42/toolkit/components/extensions/child/ext-storage.js#22-26)
- [`XPCOMUtils.defineLazyModuleGetters(...)`](https://searchfox.org/mozilla-central/search?q=Services%3A+&path=ext-*&case=false&regexp=false)

All these three shouldn't be conflict with each other because:
- we do cover this by loading all WebExtensions API modules natively integrated in Firefox itself to be sure we don't have conflicts like this
- and also because `var { Services } ...` doesn't prevent `ChromeUtils.defineModuleGetter` to redefine the same variable (and `XPCOMUtils.defineLazyModuleGetter` does use `ChromeUtils.defineModuleGetter`)

My guess is that there is another experimental API that is likely doing `const { Services } = ChromeUtils.import(...)`, because I'm pretty sure that would trigger that error.

I do also suspect that the experimental API that is actually doing that may actually be out of the mozilla-central tree because:

- it doesn't seem there is any code doing `const { Services...` in tree: https://searchfox.org/mozilla-central/search?q=const+%7B+Services&path=ext-* (to be fair if the statement is in a multiline form my quick search of searchfox may be missing it, but I'm not sure that would be something used in tree because Services.jsm doesn't export anything else and I would expect prettier to enforce that statement to be formatted on a single line)

- I was initially able to reproduce it on today's vanilla mozilla-central tip on every `./mach run`, but then while investigating it I wasn't able to reproduce it anymore (which made me think that the experimental API introducing the conflict may be actually something that instance got by other means (maybe a privileged addon installed through normandy?), and once it was gone (I have likely recreated the tmp profile from scratch a couple of times while investigating the issue) the issue wasn't triggered anymore

(I regret that I didn't look and save the about:support details when I was able to reproduce it, so that I could then compare it to the one got after I wasn't able to reproduce it again).

I did double-check how Services is imported or lazily imported in all other API modules which are part of Firefox and we do have all these three variations:

- [`var { Services } = ChromeUtils.import(...)`](https://searchfox.org/mozilla-central/search?q=var+%7B+Services+%7D+%3D+ChromeUtils.import%28&path=ext-*.js)
- [`ChromeUtils.defineModuleGetter(...`](https://searchfox.org/mozilla-central/rev/2b99ea2e97eef00a8a1c7e24e5fe51ab5304bc42/toolkit/components/extensions/child/ext-storage.js#22-26)
- [`XPCOMUtils.defineLazyModuleGetters(...)`](https://searchfox.org/mozilla-central/search?q=Services%3A+&path=ext-*&case=false&regexp=false)

All these three shouldn't be conflict with each other because:
- we do cover this by loading all WebExtensions API modules natively integrated in Firefox itself to be sure we don't have conflicts like this
- and also because `var { Services } ...` doesn't prevent `ChromeUtils.defineModuleGetter` to redefine the same variable (and `XPCOMUtils.defineLazyModuleGetter` does use `ChromeUtils.defineModuleGetter`)

My guess is that there is another experimental API that is likely doing `const { Services } = ChromeUtils.import(...)`, because I'm pretty sure that would trigger that error.

I do also suspect that the experimental API that is actually doing that may actually be out of the mozilla-central tree because:

- it doesn't seem there is any code doing `const { Services...` in tree: https://searchfox.org/mozilla-central/search?q=const+%7B+Services&path=ext-* (to be fair if the statement is in a multiline form my quick search of searchfox may be missing it, but I'm not sure that would be something used in tree because Services.jsm doesn't export anything else and I would expect prettier to enforce that statement to be formatted on a single line)

- I was initially able to reproduce it on today's vanilla mozilla-central tip on every `./mach run`, but then while investigating it I wasn't able to reproduce it anymore (which made me think that the experimental API introducing the conflict may be actually something that instance got by other means (maybe a privileged addon installed through normandy?), and once it was gone (I have likely recreated the tmp profile from scratch a couple of times while investigating the issue) the issue wasn't triggered anymore

(I regret that I didn't look and save the about:support and about:studies details when I was able to reproduce it, so that I could then compare it to the one got after I wasn't able to reproduce it again).

I did double-check how Services is imported or lazily imported in all other API modules which are part of Firefox and we do have all these three variations:

- [`var { Services } = ChromeUtils.import(...)`](https://searchfox.org/mozilla-central/search?q=var+%7B+Services+%7D+%3D+ChromeUtils.import%28&path=ext-*.js)
- [`ChromeUtils.defineModuleGetter(...`](https://searchfox.org/mozilla-central/rev/2b99ea2e97eef00a8a1c7e24e5fe51ab5304bc42/toolkit/components/extensions/child/ext-storage.js#22-26)
- [`XPCOMUtils.defineLazyModuleGetters(...)`](https://searchfox.org/mozilla-central/search?q=Services%3A+&path=ext-*&case=false&regexp=false)

All these three shouldn't be conflicting with each other because:
- we do cover this by loading all WebExtensions API modules natively integrated in Firefox itself to be sure we don't have conflicts like this
- and also because `var { Services } ...` doesn't prevent `ChromeUtils.defineModuleGetter` to redefine the same variable (and `XPCOMUtils.defineLazyModuleGetter` does use `ChromeUtils.defineModuleGetter`)

My guess is that there is another experimental API that is likely doing `const { Services } = ChromeUtils.import(...)`, because I'm pretty sure that would trigger that error.

I do also suspect that the experimental API that is actually doing that may actually be out of the mozilla-central tree because:

- it doesn't seem there is any code doing `const { Services...` in tree: https://searchfox.org/mozilla-central/search?q=const+%7B+Services&path=ext-* (to be fair if the statement is in a multiline form my quick search of searchfox may be missing it, but I'm not sure that would be something used in tree because Services.jsm doesn't export anything else and I would expect prettier to enforce that statement to be formatted on a single line)

- I was initially able to reproduce it on today's vanilla mozilla-central tip on every `./mach run`, but then while investigating it I wasn't able to reproduce it anymore (which made me think that the experimental API introducing the conflict may be actually something that instance got by other means (maybe a privileged addon installed through normandy?), and once it was gone (I have likely recreated the tmp profile from scratch a couple of times while investigating the issue) the issue wasn't triggered anymore

(I regret that I didn't look and save the about:support and about:studies details when I was able to reproduce it, so that I could then compare it to the one got after I wasn't able to reproduce it again).