Browser-Extensions | karas.codes

How Making Coffee Helped Me Find a Bug

Fri, 17 Mar 2023 00:00:00 +0000

I know what you’re thinking. Did that really happened? My answer is yes, it happened.

Context

It happened a couple of months after I started working in a team that developed browser extension. I got some bug to investigate related with one key feature of its extension.

When I found a code that was the potential culprit of a bug, I just set breakpoints in the browser and started trying to incrementally move through the code to examine it.

But I had no luck. I spent a big chunk of my time trying to trigger it in different ways… but still the corner case I wanted to find was hidden.

Coffee

After a couple of minutes I needed a quick break to make a cup of coffee and to think about other approaches that I could follow to find the culprit. But when I got back to my browser and IDE I spotted that the breakpoint was active! Something had triggered the correct code.

Solution

It turned out that feature I was testing, was using idle browser API. As a name says that API was allowing the user to track a device idle state. Inside a code I found an event handler responsible for doing the rest of the work. Solving a bug was super easy in the end.

That history is still funny after couple years… I still can’t believe that I solved a bug by preparing a coffee :)

Using the Blocking webRequest API with Manifest V3

Fri, 03 Mar 2023 00:00:00 +0000

If you are on this page, you are probably extension developer that is in trouble. In this post I will try to help you introduce workaround that works.

Context

As you know a lot of APIs was removed or deprecated by introducing Manifest V3. It was advertised as change for good direction. As increased user privacy, better performance etc. Unfortunately by looking at how changes works in the runtime, what workarounds were created for a couple of problems and what changes were done since the announcing MV3, im not quite sure that this was change for good.

Declarative net request api as a cure

We could reimplement our code in order to use declarativeNetRequest, but this API won’t allow us to do everything we need - in the code we could implement action that is needed in a way that we want to.

Workaround

Are you developing enterprise and self-hosted browser extension? You are saved!

According to the Google Chrome documentation (should work on Edge too) you are able to still use blocking version of webRequest API.

You just need to add webRequestBlocking into the manifest permissions.

Are there any drawbacks of that approach?

Unfortunately, they are…

Because of some bug in Chromium project we could not run that code locally (when using unpacked version of your extension). Extension must be deployed to your enterprise domain via policy.

So testing your code could be quite tricky. I advise you to do it on internal version that is hidden from production environment and your customers. Apart from that everything works as before. Hope this API would be still available after sunsetting MV2 extensions.

Other good news, Firefox claimed that they would be still maintaining this API.

Using Conditional Breakpoints

Sat, 21 Jan 2023 00:00:00 +0000

This post would cover another tip that could make debugging process way easier. Imagine that we have registered a listener for some browser API, and we want to test how it works. Sometimes our normal break point won’t stop the code execution. That’s why we could use conditional breakpoints.

What’s conditional breakpoint?

It’s just line of code marked as normal breakpoint, but with additional condition applied. Thanks to that approach our code will stop there only if condition would be fulfilled. Take a look at example shown below.

Also in multithreaded languages e.g. like Java we could decide whether stop all threads or only one that is executing code for given class.

When we should use it?

We could use conditional breakpoints when:

we want to filter out breakpoints we don’t want to observe that time
we want to stop the code only in some specific cases
to make sure that breakpoint for event listener would stop the code execution

Debugging Manifest V3 Browser Extensions

Thu, 19 Jan 2023 00:00:00 +0000

Developers are facing with debugging code on a daily basis. When developing browser extension that is using service worker inside it could be a little hard sometimes to debug it properly. In this article I will explain how make it in easier way.

Catching actions that are done after starting a service worker

I wanted to discover a specific case when our extension is doing some task or requests right after calling a service worker. In order to catch actions done there we could use a simple trick.

In the script marked as dedicated to service worker (that applies to both JS and TS versions):

{
  "background": {
    "service_worker": "src/serviceWorker.ts"
  }
}

Instead of calling methods we want directly:

// src/serviceWorker.ts

const x = 10;
const y = 20;
const sum = x + y;
console.log("Result: " + sum);

We could do:

// src/serviceWorker.ts

// Delay in miliseconds
const delay = 15000;

setTimeout(() => {
    const x = 10;
    const y = 20;
    const sum = x + y;
    console.log("Result: " + sum);
}, delay);

That approach will give us time on opening background page after injecting local version of our extension in the browser. Thanks to that we will be able to: check all logs, network requests, breakpoints from the start.

Hope you would find this post useful!