Changes between Version 9 and Version 10 of I2P_Browser_develop_n_hacks


Ignore:
Timestamp:
Jun 10, 2019, 5:10:53 PM (6 days ago)
Author:
Meeh
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • I2P_Browser_develop_n_hacks

    v9 v10  
    1212== Howto get started with firefox ==
    1313
     14
     15
     16=== Plugins, Extensions, Add-ons, wtf? ===
     17
     18Yes this can be quite confusing to begin with. In reality it's only the webextension api inherited from Google Chrome that browser third-party developers can use.
     19However since we're so awesome we ship our own, we bypass this limit of possibilities. The reason for this is that Firefox still heavily uses the old API internally in Firefox.
     20
     21We have three main categories of "Firefox API" before they introduced [https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions WebExtensions] on top of it all:
     22
     231. Classic extensions (not restartless): these will typically overlay the browser window and run code from this overlay. Since there is one overlay per window, there will be as many code instances as browser windows. However, classic extensions can also register an XPCOM component ([https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#JavaScript_components via chrome.manifest as of Gecko 2.0]). This component will be loaded on first use and stay around for the entire browsing session. You probably want your component to load when the browser starts, for this you should register it in the profile-after-change category and implement nsIObserver.
     24
     252. Restartless extensions, also called [https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Bootstrapped_extensions bootstrapped extensions]: these cannot register overlays which makes working with the browser UI somewhat more complicated. Instead they have a bootstrap.js script that will load when the extension is activated, this context will stay around in background until the browser is shut down or the extension is disabled. You can have XPCOM components in restartless extensions as well but you will have to register them manually (via [https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIComponentRegistrar#registerFactory%28%29 nsIComponentRegistrar.registerFactory()] and [https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICategoryManager#addCategoryEntry%28%29 nsICategoryManager.addCategoryEntry()]). You will also have to take care of unregistering the component if the extension is shut down. This is unnecessary if you merely need to add an observer, [https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIObserverService#addObserver%28%29 nsIObserverService] will take any object implementing nsIObserver, not only one that has been registered as an XPCOM component. The big downside is: most MDN examples are about classic extensions and don't explain how you would do things in a restartless extension.
     26
     273. Extensions based on the [https://addons.mozilla.org/en-US/developers/builder Add-on SDK]: these are based on a framework that produces restartless extensions. The Add-on SDK has its [https://addons.mozilla.org/en-US/developers/docs/sdk/1.7/ own API] which is very different from what you usually do in Firefox extension - but it is simple, and it mostly takes care of shutting down the extension so that you don't have to do it manually. Extensions here consist of a number of modules, with main.js loading automatically and being able to load additional modules as necessary. Once loaded, each module stays around for as long as the extension is active. They run sandboxed but you can still [https://addons.mozilla.org/en-US/developers/docs/sdk/1.7/dev-guide/tutorials/chrome.html leave the sandbox] and access XPCOM directly. However, you would probably use the [https://addons.mozilla.org/en-US/developers/docs/sdk/1.7/packages/api-utils/observer-service.html internal observer-service] module instead.
    1428
    1529