use a JSM to make messenger globally avail

[jobisoft]

This is using a JSM based approach. I use that with my Quicktext add-on. In a startup script which is executed before the WL starts listening, the WebExtension messenger object is passed from the WL into a latexit JSM. This JSM can now be loaded into any legacy context via

    var { latexit } = ChromeUtils.import("chrome://tblatex/content/legacy/latexit.jsm");
    console.log(latexit.messenger.runtime.PlatformOs);

The JSM also loads the preferences script, so it can be used from legacy pages by loading the JSM and calling

  latextit.preferences.getPref();

[sphh]

Thanks @jobisoft!

After sleeping on it, I tend to follow this path (subject to @protz's approval):

1. The purpose of the freshrun page is to find the paths to the latex and dvipng executables.
2. The firstrun page and the autodetection dialog (started from the configuration page) are the very same page and its purpose is to autodetect these executables.
3. The functionality of the firstrun page to autodetect the executable could be incorporated into the configuration page.
4. Then we can open the configuration page on a fresh install instead of the firstrun page and
5. We could get rid of the firstrun page and logic.

So my questions are:

1. Is it possible to open the configuration page on a fresh install?
2. Do you have an example of a working configuration page, because https://github.com/protz/LatexIt/blob/mailextension/content/options.xhtml gives a parsing error. (https://codebeautify.org/xmlvalidator declares it a valid xml, but https://www.w3schools.com/xml/xml_validator.asp believes it is invalid)

I already added

  "options_ui": {
    "page": "content/options.xhtml",
    "open_in_tab": false,
    "browser_style": true
  },

to manifest.json, so that I can open the preferences page from the add-ons tab.

[jobisoft]

Do not change too many things at once. The options_ui needs a pure HTML file without XUL support, so when you want to move away from the WL options page (which still supports XUL) to the options_ui option page you will have to convert the page itself. You will have to do that eventually, but I do not see an immediate need to do that now. It complicates things.

Is it possible to open the configuration page on a fresh install?

Yes, the WL has an openOptionsDialog method, see usage here. To do that on startup, you would need to use the windows API to learn if a main window is open or register a listener to learn when it has been opened and pass its windowId to openOptionsDialog.

The same is valid for the options_ui page, it can be opened via the runtime API.

Do you have an example of a working configuration page,

See my comment about options_ui needing a pure HTML page.

I suggest making only the minimal needed changes to move from prefBranch to local storage, get your current option pages working (the save issue) and if that all works (which would be a working release) think about reworking your pages in a second step.

[sphh]

Yes, you are right, that changing too many things at once is not a good idea. I just thought, if I (well, we!) tackle the options_ui first, we might not need the firstrun page at all! That will be step 2 after a working option page and local storage.

Thank you for your comments about the options_ui. I'll give it a try.

[jobisoft]

After having worked on multiple add-ons, I no longer propose this step. JSM's are not supported by WebExtensions (only ES6 modules) and the entire concept of scope sharing is going away. So do not invest time in this.