Communication in Google Chrome browser extension

Akash
WhatfixEngineeringBlog
4 min readDec 15, 2021

Communication within different parts of the Chrome browser extension is one of the primary aspects in browser extension development. This post is about passing messages between Content script, Background and content(Browser action). Simply speaking how does a script in the scope of a website talk to the extension or the other way around.

Before we get to the topic I want to outline a fairly common communication model that is used. All event handlers receive an event object containing a data property, it includes data sent as part of the message.The event model is mostly around onMessage and postMessage.

Extensions have several components to perform various actions. Most common ones are the content script and background script.
Let’s have a quick look at these shall we.

Background script — This script runs regardless of the website. Scripts run in the background of the extension and keep running until the extension is unloaded from the browser. More info on the google documentation here.
Action Script — Local JavaScript file for the extension DOM. More on Action script here.
Content script
— this is JavaScript injected by extension into the web page. The injection can be targeted to one or more web pages. This script acts like a broker between the web site DOM and the actions of the background script. More info here.

Note: I have used Manifest V2 along with this article and all the nuances are in point of view to V2.

Since Chrome extensions are event-driven because of their architecture, once the injected scripts have access to the page’s variables and functions, they can pass it to the content script.
The content script then passes these objects to the background page.
And finally, the action script is able to call onto the background page using the Extension API and pass it to the Extension DOM.

Let’s now build a simple extension who’s job is to print the performance metrics of the web application. The extension will receive performance metrics from a global object on the window and pass onto the action script to render it on the DOM, the extension DOM.

Starting with the content script, let’s start coding. Inject content script into the web application DOM.

Content script now should also start listening to messages. Essentially from the script running in the web app context. Making content script as the foreground communicator or mediator in the extension architecture.

When a message is received by content script from the custom/injected script, a quick validation for the event source is run and next simply we use the chrome extension’s runtime API to send the data further to the background script of the extension.

Now let’s have a look on how the injected custom script looks like which runs in the context on the web application layer. We know that this script has access to window functions and variables. So let’s get hands on the required object from the page’s context.

The performance data procured is now sent via post message. Custom script uses window.postMessage function for safe communication. To observe the interim changes to the performance data we will go about adding a time interval. Although this is ironic to use an interval to observe performance metrics, hence is not suggested in the real world.

We are now at the Background Script.
The background script listens for any message broadcast by the content script via Chrome Runtime API, essentially on receiving the event we can use tabId as an identifier per tab and map the essential data to. The background script’s window object will store details in memory.

Action script is what finally reads the data so as to append to the extension DOM and render performance metrics to the user about the web application.

In the popup script, the performance data is retrieved from the background script context. Using getBackgroundPage, and at an interval the current page’s details are fetched.

This way we will finally receive the essential performance data required to render it to the user over the extension’s DOM i.e., the popup page. UI styling and rendering over the extension DOM can be tweaked as per need. Now all that we have is the metrics to render.

Final thoughts

Chrome extension or be it any modern day browser extension is a powerful tool provided by the browser and by leveraging the concept of messaging between the application and the extension it holds the potential to address complex problems.

I had an opportunity to work on communication in the chrome extension for one of our use cases at Whatfix. Hopefully, this simple walk-through saves time and infers knowledge on the concept.
I would highly recommend building an extension and playground with the config and code.

Ciao for now, Happy coding!

--

--