In the previous post you could read about the main parts of an extension. Short and just the definitions. Let’s see them in practice.
Developing this way requires only a few extra thing to do.
- You need to compile typescript files. But doing this is supported by gulp. You can easily add automation to do it with a single gulp library, called gulp-typescript.
Here is the structure for my source.
Well separated parts: Background, Content, UI, Manifest like the architectural parts of an extension + Common and Assets. Files in this structure will be explained in the following sections.
Other infrastructural elements of my solution.
- Gulpfile for automation
- package.json for libraries installed with npm
- tsd.json for type defintions installed with tsd
- gitignore for github
- and dist for gulp-generated, package-ready files.
We have these parts: Background page, extension’s UI and content script.
What we have in common, they all communicate with each other.
Messaging connects all of them.
So for a good extension skeleton we need a good messaging system.
In my solution I built a base class for all my components that contains the mechanism of messaging. My implementation based on broadcasting.
From content scripts we send a message which one all the background scripts based on my baseClass will get but only the subscribed ones will handle it. One event could be important for more parts of the background components. Same from the extension’s UI.
Background scripts will broadcast their messages to the content scripts and UI scripts as well. UI scripts can’t communicate direct with the content scripts but through the background script they can. Sending the message from UI to the background script and forwarding from the background script to the content script that’s how it could work.
Every base class have the same functionality.
In the constructor you pass the event handler of your actual component for the browsers event handler. Browser part will be explained in the next section – these are the common, browser independent parts.
You have this base class with two arrays for all your component’s classes. Listeners and pending responses. Storing them and checking them at every action will provide that you didn’t lost any message or reply in the extension’s messaging traffic.
As an example. I created the test file. It defines its event subscriptions in the constructor. Other classes extending the base class will have own arrays for all of that. Every component will know for which events they interested or for which ones not.
The actual ‘on’ subscribing method adds only this subscription to the array. Going through the array and checking which events to handle will happen if the browsers listener will get a message.
Sending a message will be the preparation of a well defined event package and the triggering of the event. Triggering is different in the different browsers that’s why it is only a method here, a method of the browser.
Browser & Component differences of messaging
As I mentioned all the base classes are only duplicates. In the code yes, but in every component we will use a different browser implementations. So we will have browser file for Background scripts, Content Scripts and UI scripts as well. First I will show you these differences. So the different browser implementations of the different components. After that I will show the actual browser differences, that are because of the two different browser, Chrome and Firefox.
Isn’t clear yet? – No problem. I will show everything in practice. I hope it will make things clear.
chrome.runtime.onMessage.addListener is the method of the chrome API to handle event subscriptions. If we get a message we will iterate through all of our subscribed class’s callback – remember base class passed in its constructor to the browser implementation – and call them with the actual event data.
Filling this array, the eventListeners array happens through the eventReceived method.
Sending a message from background scripts has two steps. Sending the actual message to the scripts in the UI and sending them to the content scripts. Both have different ways.
UI can communicate directly through the run-time with the background script so we can use it to deliver messages from one to other. But as I mentioned it in my previous post, Content scripts are not part of the extensions technically. They will get the messages through the actual page, into they are actually injected. We can get all the pages opened in the browser in our background script with the chrome.tabs.query and we can send the message to all of them. Only the page containing our injected logic with the event handlers will do something with the message the others will ignore it.
Content script & UI scripts (Popup):
Background need to use other method to send message to Content Scripts and UI scripts but they can get messages through the run-time and can use it to sending the messages as well in the same way.
The type in the sendMessage is for the browser. Extension communication go through the type, message. In the payload we can define our type as well. Identifying our messages with our types/names.
UI scripts implementation is for popup types, not for panel types. It is differentiated in chrome. More about it you can find in my skeleton implementation.
Messaging in Firefox looks different. In background scripts you have to create a panel as the main component of your extension. It has a port, we can use for sending and getting messages.
In content scripts and UI scripts we have a ‘self‘ or ‘addon‘ object with the port or we can use the window object for sending and listening events. More about it you can find in my skeleton implementation.
Other browser differences
We need to hide more differences not just messaging. So little things like timeouts are different in the browser.
In Chrome background scripts you can use a fully featured window object, but in Firefox you don’t have the timeout functions on that. You have a timers SDK to use for that.
In Chrome you can use the chrome.* objects and methods.
In Firefox you need to use the underlying module handler – the built in CommonJs for getting the SDK’s libraries.
More feature that needs different implementations according to the actual browser will come. In the skeleton I needed only these ones. I think in later posts there will be more about this differences. Don’t miss them.
Bootstrapping the extensions are very different in the two browsers.
Chrome uses the manifest.json for all the things.
It will bind the Ctrl + B key-combo to start our UI. The UI will be the default_popup’s html. We define the background scripts and the content scripts as well. Chrome will know what to do with them.
Firefox have a few details in the package.json file.
It defines only the path of the background script and Firefox will use the background script and the browser’s SDK to create the parts of the extension.
You define here the panel and it properties. The icon (= button) in the browser’s toolbar. It handles the show and hide of the extension’s UI. Injecting the content scripts happens also here with the pageMod SDK library.
In case of content scripts the * defines that we want our script injected into every opened tab, we define the path of the script and we want to load and run the script on document ready event.
In Chrome (previous picture) matches: <all_urls> is the same with the * in Firefox. Js defines the path. Run_at is the same as contentScriptWhen. In Chrome we have an extra option to include our script not just into the page but into all of the iframes the page contains. Firefox uses other option to do that.
All the sources mentioned in this article you can find in my repository in github. You can check it: https://github.com/FerencKun/extensionbase
If we are ready with the development we need a good automatized infrastructure to build the files and prepare them for packaging and publishing.
Automations with gulp
Developing an extension for both browsers. Chrome and Firefox. Without gulp could be very hard. Gulp task can help us make the right package for both browser with a little configuration and with parameterized tasks. Here I don’t have space to define what gulp is. Please let me speak about it so as if you would know the basics of this technology and if you didn’t, here are some good links to learn more about gulp.
One big difference is that in Chrome we can add more background scripts but in Firefox we can only define one file. So we need to concat all the background scripts into one.
We can add our different browser files with the gulp task in our copy task but we need different path settings in html files. (If we don’t want to rename our destination files.) There is an option to do it with gulp as well.
We can define string patterns (with custom prefixes) to replace with value in that place too. In html I will define //@@browserFilePath and gulp will replace it with chrome.js or with firefox.js according to the parameter.
Now we have the already ready files to package them for the browsers. About packaging and and publishing I will write about later. I hope this much content will be enough for this post. But more info in this theme will be coming soon.
To be continued…