Skip to main content

From MV2 to MV3: How Dashlane Prepares for the Transition

  |  Tristan Parisot

The web browser world is constantly evolving. One large, ongoing change is called Manifest V3 (MV3)—a completely new architecture model for Chrome extensions that aims to enhance security, privacy, and performance. To quote Google, “Manifest V3 represents one of the most significant shifts in the extensions platform since it launched a decade ago.”

We have been actively involved in the W3C Web Extension Community Group since it launched in June 2021 to help shape and influence the future of web extensions. With Chromium-based browsers representing 70% or more of today’s market, here’s how Dashlane is planning for a world of MV3 Chrome extensions.

Dashlane’s transition from MV2 to MV3

The Dashlane Chrome extension currently runs in Manifest V2. Let’s take a look at one of the architecture pattern changes impacting the extension.

In Manifest V2, the extension uses a background page to allow the different components of the Dashlane extension to operate together. The background page is actually a hidden webpage, and Dashlane used it to keep data in memory after loading it from the disk.

Screenshots of the Dashlane web app, the Dashlane pop-up, and a website with an extension window asking to save a login to Dashlane. All of these windows have an arrow pointing from them to a box that says “background.

In MV3, there are no background pages anymore. Instead, a service worker is started when needed and terminated shortly after. We are moving from a persistent environment in MV2 to an event-based, ephemeral environment in MV3. As you can imagine, it is a massive paradigm shift for an extension such as Dashlane.

We have been extensively refactoring the Dashlane extension’s code to prepare for the transition from MV2 to MV3 so it can work seamlessly either with a background page or a service worker.

The code has been going to production progressively, even though it is not “active,” and the Dashlane production extension is still running in MV2. This way, we gradually release changes and new features to avoid a big, one-time migration with lots of potential surprises.

Dashlane’s recent challenges and fixes with MV3

Let’s zoom inside the background page:

A diagram representing a background page. At the top are three rectangles labeled “Web app,” “Pop-up,” and “Website pages.” Below them, there is a larger rectangle labeled “Communication layer” with a smaller rectangle within labeled “Retry mechanism.” An arrow points down into the largest box, labeled “Background page,” and within that, a rectangle labeled “Features logic” contains three boxes, labeled “Vault,” “Password health,” and “...” respectively.

The Dashlane extension background page has a communication layer that establishes a bridge between the extension user interfaces and the features logic. This communication layer allows the Dashlane extension to work seamlessly in Manifest V2. The biggest impact in Manifest v3 is that the backend code containing the logic for our features can be terminated at any time. Therefore, we added a retry mechanism to this layer to ensure the communication stays open between the different components of the extension.

That retry mechanism generated a very slow memory leak and ended up with memory and CPU performance degradation over time. It was supposed to re-send messages only in case of service worker termination, but a bug made it re-send some messages indefinitely. This was a tricky issue to identify as it was related to our MV3 refactor, which is not live today for customers, but the code is in production nevertheless. In addition, it appeared after a long time under specific conditions.

This bug required different fixes to mitigate the impact:

  • We optimized the CPU impact of sending a message via the communication layer, but that was not enough. After a couple of days of usage, the CPU usage still started to get high, which explains why it took some time to detect the issue.
  • Then, we removed the messages that were re-sent incorrectly to the communication layer.
  • In the end, the message retry mechanism had to be rewritten so that messages would only be re-sent when the feature logic container (background page or service worker) becomes unavailable, then available again.

We worked hard to swiftly resolve this bug, and we continue to monitor and improve performance.

What’s next?

We’re still actively working on the transition to MV3, and we will share more of our experience and lessons on our blog. MV3 is a big change with significant risks involved, so we want to level up on testing and ensure we make it as smooth a transition as possible.

At the same time, Google is still evolving the MV3 support in Chrome, which is something we need to factor in.

We soon plan to launch a beta phase of the Dashlane MV3 extension so we can get more real-life usage and make sure we reach the best quality possible. (Do you want to get an early chance to try out our new extension? Sign up for our beta program!) Monitoring and observing the MV3 extension is a major priority for us.

Stay tuned for more on our MV3 journey on our blog. And if you have a question or comment, feel free to reach out.

Sign up to receive news and updates about Dashlane