For my web extension I would like to have a "debug mode" which makes troubleshooting issues with the extension easier. By default this debug mode should be disabled, but it should be possible to enable it at runtime.

I don't have a settings page for the extension yet (and am also not planning on adding one soon), so I don't want to create one just for enabling this debug mode. Also the debug mode should hopefully rarely be needed.

Therefore one approach I was thinking of is using the Console of the background script when debugging the extension in the browser (Firefox, Chrome), to somehow inform the background script or modify its state to enable the "debug mode" of my extension.

For Firefox and Chrome what seems to work is:

• In the debug Console set a custom window property / global variable, for example myExtDebug = true
• In the background script check window.myExtDebug === true

However, my questions are:

• Are there any downsides of this window approach, for example security-wise? How reliable is it / to what extent does it rely on implementation details?
  (Note that I am using a property name which includes the name of my extension, so chances of an accidental collision with another property should be low.)
• What other approaches exist?

For my web extension I would like to have a "debug mode" which makes troubleshooting issues with the extension easier. By default this debug mode should be disabled, but it should be possible to enable it at runtime.

I don't have a settings page for the extension yet (and am also not planning on adding one soon), so I don't want to create one just for enabling this debug mode. Also the debug mode should hopefully rarely be needed.

Therefore one approach I was thinking of is using the Console of the background script when debugging the extension in the browser (Firefox, Chrome), to somehow inform the background script or modify its state to enable the "debug mode" of my extension.

For Firefox and Chrome what seems to work is:

• In the debug Console set a custom window property / global variable, for example myExtDebug = true
• In the background script check window.myExtDebug === true

However, my questions are:

• Are there any downsides of this window approach, for example security-wise? How reliable is it / to what extent does it rely on implementation details?
  (Note that I am using a property name which includes the name of my extension, so chances of an accidental collision with another property should be low.)
• What other approaches exist?

• google-chrome-extension
• firefox-addon-webextensions
• web-extension

• There are no downsides and no security concerns either. This is conceptually the same as a global variable. – woxxom Commented Mar 28 at 2:55
• @woxxom, so this is a reasonable approach? I am quite happy with it, but I was wondering to what extent this relies on implementation details or misuses features. And also wasn't sure why it doesn't work on Chrome (though I am still using Manifest v2, so probably cannot support Chrome in the future anyway, so not so important). Feel free to add your information as answer, and I will mark it as accepted. – Marcono1234 Commented Mar 30 at 11:53
• Edit: The window approach works for Chrome as well. Must have done something wrong during initial testing. Have updated the question now. – Marcono1234 Commented Mar 30 at 12:06

1 Answer 1

The Mozilla documentation says:

Background scripts run in the context of a special page called a background page. This gives them a window global

Which suggests the approach of using window might be officially supported.

For Chrome since Manifest v3 there are no background scripts and pages anymore, instead service workers have to be used. They don't seem to have access to window but there is the concept of an offscreen document (not sure if this can be used for the purpose of the question).

(Note: This just describes my observations. Feel free to add your own answer if you can provide more information.)