You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
When installed, the system add-on should make some form of API available to a whitelisted set of domains that allows them to execute actions in "testing" mode. This will be used on the preview page in the control interface to preview how a recipe will behave.
The one difference between using Services.mm and the message manager that UITour uses is that UITour's will only see events from webpages loaded in tab while Services.mm will see events from any webpage, so for example the sidebar, webextension panels etc. Since you're going to be doing domain checking I wouldn't expect that to be an issue though but if needs be you can do additional verification when sending a message up to the main process that the page is actually in a tab.
@Mossop@gijsk I have a question while I'm looking over the UITour implementation:
UITour uses nsiPermissionManager to check for origins that have permission to use UITour, and add the origins they care about to the list of default permissions. However, as a system add-on, we'd have to manually add the origins we care about on startup to the permissions manager anyway (or at least once; I can't tell if they persist after being added).
Given that, is there any point to using nsiPermissionManager if we're going to be doing our own domain checking for test origins anyway?