Getting started

 1. What is a module?

Module is a functionally completed extension component executed as several files with the source code.

Each module may contain several parts:

  • Background scripts
  • Foreground scripts
  • Pop-up scripts
  • Files
  • Styles
  • Resources


1.1 Background scripts

The background script is a script which runs in the extension process. It exists for the lifetime of your extension, and only one instance of it at a time is active.


1.2 Foreground  scripts

If your extension needs to interact with web pages, then it needs a foreground scripts. It’s some JavaScript that executes in the context of a page that's been loaded into the browser. Foreground scripts can read details of the web pages the browser visits, and they can read and modify the DOM for the displayed web page. Foreground scripts run on each webpage opened by user.


1.3 Pop-up scripts

If your extension has a pop-up, the pop-up appears when the user clicks the browser button icon. A pop-up is a HTML-window that pops up over the browser button. The pop-up window closes automatically when user changes focus (by clicking on another window, for example). The pop-up can contain any HTML contents that you like, but you should create it dinamically. In the pop-up you can use any KERNEL’s API that are available in the background scripts. Also, pop-up page reloads automatically each time that it has been opened.


1.4 Files

Each module may include any files. If you want to store something in the extension’s package you should place all neccessary files into the folder "Files" in the root module’s directory and all that files will be available in the extension. You can use images or other media content in the CSS/UI as it will be described below. Or you can use that files from your scripts.


1.5 Styles

Each module may include several CSS files. But you can use @import  only for the external styles.

If you want to use embedded media files such as images from the Files folder, you should use follow scheme for url(..) directive ab://module_name/relative_file_path.


For better understanding of the theory please see the scheme below: 


2. Extension architecture

Your background code will be loaded into high-priveleged browser scope that will be existing only for the lifetime of your extension. It can use all available API for any purpose. Also, foreground scripts will be injected into all opened pages and may interact with user, loaded page or just do something cool.

Anyway foreground scripts has less privileges and many API functions are unavailable in the foreground scripts. However foreground scripts may interact with background scripts as well as background scripts may interact with all running foreground scripts.

In some of the existing API that will be described below unique id is used for the identifying target or source contexts.

For better understanding code interactions you should keep in your mind the following rules:

  • you can identify your foreground scripts by unique id which will be similar to unique tab id;
  • each opened browser tab has unique and constant id from the moment when user opened it until this tab will be closed;
  • background scripts id is always "0". 


Developing your modules keep in mind that they should work correctly in all modern browsers!