Accessing website's window object in Chrome extension

Lore

So, recently I've been working on a Chrome extension that would speed up the debugging workflow in our team. We wanted a quick way to share current user's cart state without involving our production code in any way.

Sounds easy right?
Well... it wasn't.

Turns out that making a Chrome extension that has access to website's window object isn't as easy as it may seem.

Different worlds

On the frontend we use a library that is available as a global variable on the window object (to share it between components in our micro-frontend architecture).

For the purpose of this article let's call it window.library

When we click a button in our extension popup we want to access that library and call a function on it. Content script should do just fine.
But calling window.library.some.thing ends up with a classic in the console:

TypeError: Cannot read properties of undefined (reading 'some')

It surely exists, I can see it in the console. Why can't I access it?
Well, Chrome has a feature called Execution Worlds. You can read more about it here.

Here's a TDLR from the docs:

The JavaScript world for a script to execute within. Defaults to "ISOLATED", which is the execution environment unique to the content script. Choosing the "MAIN" world means the script will share the execution environment with the host page's JavaScript.

So, now it makes sense. If our content script is executed in an ISOLATED world it won't have access to the window object of the host page. Let's change it to "MAIN" and everything would be fine, right?

Kinda...

When we set the world to "MAIN" we can access the window object of the host page. BUT, we loose access to chrome.* apis. That's a bummer.

Inter-world communication using a bit of postMessage()

Nothing is lost though. Chrome allows us to place multiple content scripts on the same page... Aaand to do so with different execution worlds in each of them. PERFECT!
Our content scripts now look like this:

"content_scripts": [
    {
      // ...
      "js": ["isolated.js"],
      // "world" defaults to ISOLATED so you can ommit this line
      "world": "ISOLATED"
    },
    {
      // ...
      "js": ["main.js"],
      "world": "MAIN"
    }
],

So now we have to find a way to communicate between these two content scripts. Luckily we have: window.postMessage() and window.addEventListener('message')

We can use it to send messages between these two worlds. Later our content script in the ISOLATED world can communicate with the extension's popup using chrome.runtime.sendMessage() and chrome.runtime.onMessage.addListener()

Here is a simple diagram that illustrates how it works:

A few things to consider

Doing it this way has a few drawbacks:

• You have to send messages to communicate which complicates codebase quite a bit.
• You have to be careful with the data you send. It has to be serializable.
• Using MAIN world has a few drawbacks by itself:
  • You can't use chrome.* apis in the content script.
  • Other scripts, extensions and the page itself can access your content script's variables and functions (duh).
  • Some bundlers by default minify names of variables and functions. Which can lead to clashes with other global variables and functions on the page.

You can read more about concept of worlds here

I should go,

Krystian