Firefox sometimes goes ridiculously slow with an extension

This is a comment on our extension Container Tab Groups.

This is the closest I’ve come to using an extension that provides what I liked about Panorama. I like being able to sort and create new categories in the sidebar but for whatever reason when I use this extension from time to time pages will no longer load. I’ll see the loading animation on the tab but nothing appears. When I turn this extension off then the page loads normally. It’s frustrating and it’s the one problem I have with this extension. Even when I clear the browser cache and history then quit and reopen Firefox it still happens.

Also in my testing environment, Firefox is sometimes too slow to load any pages with this extension enabled. Disabling the extension fixes the problem, but I think it to be a some sort of Firefox issue, because any call to WebExtensions API takes too much time and freezes the browser when this problem occurs.

Certainly Container Tab Groups (CTG) registers many listeners/handlers on various parts of web requests.

  • webRequest.onBeforeRequest to redirect requests.
  • webRequest.onBeforeSendHeaders to override some request headers (e.g. User-Agent and Accept-Languages).
  • webRequest.onHeadersReceived to make some changes to response headers. (this might not be needed, so I am considering removing it)
  • proxy.onRequest to set per-container proxies.
  • webRequest.onAuthRequired to provide HTTP-proxy credentials.
  • webRequest.onCompleted/webRequest.onErrorOccurred to clear pending requests list to correctly handle proxy requests.

When the problem happens, WebExtensions API calls in the listeners become too slow and block page load for a long time.

Do you other extension developers have similar problems?

We made the following changes to the extension (unreleased).

Remove usage of webRequest.onHeadersReceived:

We are using storage API instead of having variables on a background script, to migration to a non-persistent background script or MV3 easier.
However, we made changes so that storage values are cached whenever possible. If cache is missing (due to background script pause/resume), the storage value is fetched.

We have also removed unnecesary alarms before (released as 11.8.1).

We are making every change possible to make the extension faster, but Firefox sometimes freezes or HTTP requests take too much time.

From what I can see after a quick look-see :slight_smile: , you are doing way to many and expensive operations in the time-critical parts of the code. Note that exactly this is one of the reasons the MV3 disabled this request blocking API.

Let’s see, here you register onBeforeRequest:


Which calls this for each request:

This is way too many async operations - use performance.now() to measure how long it takes for this function to finish :slight_smile:.

And then for those that needs redirect you call registerUrl:

And this will read and write into storage! It better be some in-memory store.
If not, then that’s two IO operations!

Quick tips when working with blocking requests API:

  • use filter to limit number of requests you are watching
  • avoid “async” operations whenever possible - this includes all those browser API. If you can’t avoid them, cache them. Page can make 100 requests or even much more with a single load.
  • avoid any IO operations! Use in-memory storage and if needed, serialize later in batches.
  • use as little code as possible - the more code / API / libraries you use, the higher chance for memory leak. Most libraries is not build for “performance”.
1 Like

I made changes so that every storage operation in request handlers is cached. Also, some IO operations are stored in memory and later committed in batch.

However, non-persistent nature of MV3 background pages prevent me from using an in-memory store.

1 Like

By the way, our webRequest.onBeforeRequest blocking listener returns immediately if it is in a container, so performance is a problem only for users who use the default container intensively.

Our test indicates that the updated version is faster visibly. Only sometimes slow-downs occur, but not never.

For example, in my main PC, this page previously took a minute to load, but now it loads instantly.