Background user scripts in Manifest V3?

[Hans R.]

Hi fellow developers.

I'd like to request for comments from any Google official that keeps an eye on this forum about the following use case.

Our extension (ID: lkaihdpfpifdlgoapbfocpmekbokmcfd), allows users to write scripts that instead of running in a specific tab, they run in the background.

Our current implementation is to run these scripts in a sandboxed iframe embedded in the extension's background page. This allows for safe execution of arbitrary code and the extension doesn't need to request the use of unsafe eval.

More info at: https://developer.chrome.com/extensions/sandboxingEval

This feature enables users to execute long-running scripts that won't be terminated inadvertently when tabs are closed or navigated away, as the script is not running on any tab or page that the user can close intentionally or unintentionally.

When this functionality is put together with the "background" permission, it allows scripts to persist even after all tabs and windows have been closed.

We document this feature on the following page:

https://www.autocontrol.app/scripting/background-scripts

Users can use this type of scripts to manipulate their tabs and to automate tasks in ways that the extension doesn't readily allow with its default stock of actions. i.e. users can build their own custom actions by scripting the extension's base functionality thanks to an API we provide for this purpose.

As I've read in this forum, Manifest V3 will allow the execution of arbitrary code, although the mechanism for doing so hasn't been announced or documented so far.

So, here comes the question... and straight to the point.

Will Manifest V3 allow this functionality?

I understand that MV3 is still in the design phase, so you may not be able to answer the question with a straight yes or no. In which case I'd like to ask if there are plans to support this use case in any shape or form or at least if you are willing to support it somehow.

I look forward to your comments.

Best regards.

Hans R.

[wOxxOm]

A year ago when ManifestV3 was announced I indicated that it'll break these features i.e. a) sandboxed frames in background pages and b) background scripts with complex state. It was ignored back then. It's easy to ignore me, I concede, as I only keep exposing the weak points of the API and the team, which since then turned out to have no time to support these admittedly rare cases on top of the standard service workers. They even switched to service workers because they didn't have time/desire to keep maintaining the classic background pages that are based on a renderer process model same as one used for the sites in tabs.

Realistically, I very much doubt an ability to add DOM things like frames would be added to a service worker specification any time soon if at all as they were designed to be complementary to a web page front-end that can process DOM natively. And the team doesn't have time to implement it on top of the spec just for ManifestV3.

The only workaround would be to keep a separate visible tab. It's kinda pathetic, but you can trick users into thinking it's for their own benefit by adding some fancy UI with gears/states/meters, and you can pin the tab to slightly reduce the possibility of accidental closing, which can be also safeguarded by adding a `beforeunload` event handler so the browser would display a confirmation prompt in that case.

I wonder if ManifestV3 could somehow make use of SharedWorker...

[Getfree]

I've read more than once about this theory that the extensions team doesn't have the time to keep maintaining the background-page functionality.

Honestly, I find this hard to believe. A background page is just a hidden browser window. Actually, it's not even a window, it's just the rendered process.

So, implementing a background page is as easy as this:

1. Create a browser window and load the extension page in it

2. Hide the window

3. Exclude the window/tab from the chrome.windows.getAll and chrome.tabs.query APIs.

That's it. I've just implemented the background page functionality for you Chrome team. It's really that simple because the background page is no different from any other extension page.

As wOxxOm says, you can emulate the background page with a regular browser tab, without changing a single line of code in your extension other than the one extra line that creates the tab.

If the current implementation of the background page in Chrome is anything more complicated than this, then it's unnecessary and it can be (and should be) simplified. There's no reason for such a simple feature to have significant maintenance cost.

So, the Chrome team is obviously aiming at something else with this whole MV3 debacle. One goal that's rather clear from the document they published is efficiency. Apparently, according to their usage metrics, extensions make the browsing experience feel sluggish for a lot of users. By removing the background page they are probably hoping to save some RAM in the user's computer. Other than that I see no benefit at all.

On the other hand, MV3 will force extensions to constantly save and load their state to chrome.storage (which is a JSON encoded data store). The few dozen megabytes they will save by removing the background page will have the cost of more CPU usage for having to load and unload data each time the service worker is started/finished.

[Simeon Vincent]

Will Manifest V3 allow this functionality? - Hans

I'm not certain. We've discussed ways to enable user scripting and styling extensions in Manifest V3, but we haven't discussed allowing user scripts or remotely hosted scripts in background contexts. If we do user scripts to execute in a background contexts, there will certainly be adaptations required to make them work as desired.

When this functionality is put together with the "background" permission, it allows scripts to persist even after all tabs and windows have been closed. - Hans

I don't believe the background permission is changing, but the long lived execution environment of the background page is being replaced with a service worker. I expect that this will have two main impacts on your extension.

First, service workers do not have a host document, so you will not be able to use iframes or other DOM capabilities for script isolation. You could wrap user scripts in an immediately invoked function expression and shim the globals available to the function in order to construct a sandbox. Another option is to use workers to handle use scripts. Workers would provide better isolation guarantees while requiring more up front work to implement. 

Second, the ephemeral nature of service workers means that you'll likely have to shim extension APIs to properly handle asynchronous operations. For example, if a user script wanted to register a callback for chrome.tabs.onUpdated, that registration call would best be performed at the top level of your main script. You'll then need to capture and dispatch the event to the appropriate user scripts once they've been re-initialized.

Hans, I have some thoughts about your GUI. - Simeon

I needed a section divider and didn't have a quote to reference. ¯\_(ツ)_/¯ Anyway, your GUI is interesting because it looks like it fits well into the pattern of using config rather than code. If you are using config to drive a state machine or other internal logic at runtime, this should work within Manifest V3's remotely hosted code restrictions. If you're dynamically constructing a string that's evaled at runtime… well, you'll need to keep an eye out for updates.

I wonder if ManifestV3 could somehow make use of SharedWorker... - wOxxOm

The most relevant issue I've seen related to this is covered by crbug.com/1032094. As I recall we had some major reservations around unbound lifetimes for shared workers. Speaking of which, I should probably jump back into that discussion. 

I've read more than once about this theory that the extensions team doesn't have the time to keep maintaining the background-page functionality. - Getfree

That framing doesn't quite sit right with me. I'll take a shot, but I'm pretty tired so this may not be fully baked.

Well it may not seem like it on the outside, the chrome team has limited time and resources. In order to get the most out of what we have, we want to focus on extensions issues rather than bugs that appear as a result of reimplementing or customizing existing features. 

There's no reason for such a simple feature to have significant maintenance cost.

If you'd like to dig into how extensions are implemented, I'd suggest starting with extensions/README.md. I'm sure the team would be open to discussing improvements.

By removing the background page they are probably hoping to save some RAM in the user's computer. Other than that I see no benefit at all. - Getfree

Off the top of my head RAM, processes, and battery are all motivators. And they're all exacerbated by badly written extension JavaScript. It's much easier to write bad code that will impact your system in a long lived environment than in a short lived one.

Cheers,

Simeon - @dotproto

Developer Advocate for Chrome Extensions

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c87e56bc-37d4-4e98-aa2d-e4ad7c68b67bo%40chromium.org.

[wOxxOm]

> Off the top of my head RAM, processes, and battery are all motivators. And they're all exacerbated by badly written extension JavaScript. It's much easier to write bad code that will impact your system in a long lived environment than in a short lived one. 

It's a largely false sentiment, unfortunately shared by more than one Chromium engineer. I will probably have to overcome my laziness and open an issue on the bug tracker to obliterate the notion with facts.

> RAM

Open a task manager in your browser and sum it up yourself. RAM usage of all extensions combined is typically [much] less than of a couple of modern sites. For users who open a lot of tabs the extensions are an insignificant blip.

> processes

Non-factor. Shouldn't have been mentioned at all. The presence of an idle extension process (that's not doing anything at all in JS) doesn't impact neither the system nor the browser: one would have to install thousands of extensions to start seeing the impact.

> battery

It would require an extension to do expensive work without any user-initiated event, which is an extremely rare scenario. Most of what extensions do is react to a user-initiated event.

It's the other way around, actually. Starting a new JavaScript environment, which will then proceed to rebuild the state is typically much more expensive (this is something that can be measured via chrome://tracing, for example) and thus will drain the battery even faster especially if an extension is navigation-driven, it can wake up like this hundreds times a day so the overall amount of work performed by the computer on account of this computer will be hundreds of times more compared to an idling persistent background script.

> It's much easier to write bad code that will impact your system in a long lived environment than in a short lived one.

False. You can't quantify these things. It's just as easy to write bad code with short-lived scripts and as the paragraph above shows for many extensions the switch to a short-lived script will itself bring an overhead so big that it will bury any benefits.

[Getfree]

On Saturday, August 15, 2020 at 11:27:09 PM UTC-4, wOxxOm wrote:

I will probably have to overcome my laziness and open an issue on the bug tracker to obliterate the notion with facts.

 

One thing I've learned about facts... is that when someone has defended a position for long enough, it's unlikely that they will ever back down, even in the face of evidence.

Out of all the changes in MV3, removing the background page is the one that makes the least sense. But they've embarked themselves on that ship too long ago already.

[Hans R.]

Thanks, Simeon, for your reply.

On Wednesday, August 12, 2020 at 3:19:46 AM UTC-4, Simeon Vincent wrote:

your GUI is interesting because it looks like it fits well into the pattern of using config rather than code. If you are using config to drive a state machine or other internal logic at runtime, this should work within Manifest V3's remotely hosted code restrictions. If you're dynamically constructing a string that's evaled at runtime… well, you'll need to keep an eye out for updates.

 

Yes, the actions defined in the GUI run in a simple sequencer. We don't need eval() or chrome.tabs.executeScript for those. But the scripting capabilities do need code evaluation, of course.

However, our biggest concern is whether we'll be able to make everything work fast as it is right now. One of our promises to our users is "shortcuts respond instantly", and we do deliver on that promise.

However, the new service worker, with its constant load/unload regime, will force us to save the entire extension state and then reload it every time the worker wakes up.

We haven't performed any tests yet, but we know for a fact that event pages have a noticeable start-up time. That's why we use a persistent background page instead. Presumably, a service worker would start slightly faster?

But then we have to add the time necessary to load, parse and execute 27 Javascript files (which is what we use in the background page right now). And on top of that the time needed to reload the extension state from storage. And only then we can respond to the user's shortcut.

We'll be very surprised (and happy) if that whole process takes no more than a blink. Otherwise, our users will become irritated and they'll start asking why their shortcuts used to work instantly and now they take half a second to respond.

[wOxxOm]

>  Presumably, a service worker would start slightly faster? 

Negligible. Compared to an event page background script, a service worker only lacks a few bindings like DOM so the improvement when switching to a worker is like 10ms, in other words it's totally negligible compared to the time needed to set up the environment itself ~100ms, and then run all your js code 100-1000ms. Performance-wise, there is no benefit that would justify the switch by itself, the switch was made mainly to simplify the source code of Chromium, AFAICT.

[Simeon Vincent]

wOxxOm, your response to my comments about RAM, processes, and battery are reasonable if you're only concerned about the middle of the bell curve. The extensions platform needs to support developers of all skill levels and devices of all capability levels. Extensions can have amazing performance characteristics when their developers prioritize those concerns, but many developers do not. While concurrent processes may not seem like a concern, I assure you that I've been a fly on the wall for a few in conversations where process count was explicitly identified as a concern.

But then we have to add the time necessary to load, parse and execute 27 Javascript files (which is what we use in the background page right now). And on top of that the time needed to reload the extension state from storage. And only then we can respond to the user's shortcut.

Is it strictly necessary to parse and execute 27 JS files or is it an artifact of the current implementation? It should be possible to react to user invocation almost instantly but that may require architecture changes or rewriting of some of your systems. 

MV3 is a different platform than MV2. The performance characteristics will be different. It will likely 

the switch was made mainly to simplify the source code of Chromium, AFAICT - wOxxOm

This reads as a bit dismissive to me, but maybe I'm just in a bad mood. I'd rephrase this to say "the switch is being made in part to improve the maintainability of the Chromium Extensions platform by leverating open web technologies in place of extension-specific ones." That may sound like a distinction without a difference, but I think it's important. 

Chrome's extension platform team is a small fraction of the engineers that work on Chrome's web platform. Service workers fill a similar role to event pages but they were designed and implemented with more attention paid to their performance characteristics and integration with the web platform. In our view it's better for us to lean on the web platform's capabilities than try to maintain our own parallel implementations. 

Cheers,

Simeon - @dotproto

Developer Advocate for Chrome Extensions

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c126c461-62f1-43ba-903b-9271474eb5cen%40chromium.org.

[wOxxOm]

> your response to my comments about RAM, processes, and battery 

My real point was that these conjectures aren't universal so citing them as the reason for a change feels contrived. I've been programming non-professionally for more than two decades so I've seen some weird cases, too. But neither mine nor your experience should substitute a properly done measurement of the extensions as a whole. No one performed such a strict investigation judging by the lack of any publicly shared data. It'd be nice if Chromium added and shared a metrics to measure some of these things (this mechanism is used a lot in Chromium) instead of using feelings/desires/experience/whatever.

>  It should be possible to react to user invocation almost instantly but that may require architecture changes or rewriting of some of your systems 

Only if we redefine "instantly" using its internet meaning where it is 100ms due to an average network request+response duration. Starting a service worker (or an event page script) will take at least 50-100ms to create the JS environment, which will be already a noticeable delay in some cases, and then usually at least 50-100ms to run something meaningful in JS so the delay will be 100-200ms.

[Scott Fortmann-Roe]

On the issue of extension performance impact, I feel the only way to solve this start by measuring the performance impact that users experience due to a specific extension and then reporting that to them.

I think most extension developers would be 100% supportive of this reporting. In our case, we have a competitor who uses 20X the Javascript we do (seems like they are blindly pulling in half of NPM) and it would be fantastic if users were made aware of that and could see how much lower our footprint and performance impact was.

I don't think switching to service workers is the right approach to addressing performance frankly. The service worker model does provide some built-in defenses against runaway extensions, but it's always going to be possible to write horribly bloated performance sucking code.

I realize this type of telemetry and analysis is a big ask and would take a lot of work, but I don't know how Google can tame poorly performing extensions other than measuring it and reporting it so that users can make informed decisions. The new extension pinning area would be a great place to show this and it should also be reported in the Webstore when users install or browse extensions.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/ddbd136c-22ee-4525-8919-bae8aa863488n%40chromium.org.

[Inter Net]

What does ` background scripts with complex state.  ` mean? Does this mean we will not be able to create Chrome Extension with ReactJS anymore because this is a client-side rendered UI with state?

[wOxxOm]

> What does ` background scripts with complex state.  ` mean? 

By "complex" I meant it's not serializable as a JSON or too big to be stored or it takes a lot of time to rebuild.  

 

> Does this mean we will not be able to create Chrome Extension with ReactJS anymore because this is a client-side rendered UI with state?

No, it doesn't mean that.

By breaking I meant some extensions will become so inefficient that it won't make sense to use them anymore. There's no problem with creating the state of any complexity in MV3. The problem is that when your state is complex as defined above, you'll have to recreate it each time the worker starts. When the state isn't trivial, recreating it takes some time, stressing the CPU all the while. If the purpose of the extension is to process some rare event, it's not a problem either. But if you process a frequent event like network navigation via chrome.webNavigation or chrome.tabs.onUpdated then all this work to recreate the state will be wasteful, it'll be an overhead that in many cases will exceed the useful portion of the event handler, in some cases by far.

[Inter Net]

I don't see how building useful extensions in V3 will be possible then.

[wOxxOm]

> I don't see how building useful extensions in V3 will be possible then.

Why though? Not all extensions really need a persistent background script, it's actually the other way around: most extensions don't. The problem I have with MV3 is that its proponents claim without any tangible proof the persistent use case is non-existent or negligible.

[Stephen Bussey]

I don't consider myself to have any crazy ground-breaking Chrome Extensions, but both of the SaaS extensions that I work on would be not-possible with the proposed V3 changes. Namely, not having a persistent BG worker.

I don't think it's an issue of the current architecture, as much as it is that our needs simply require persistent state and executing code often. Put another way: I don't think that I can simply rewrite everything to have it work for v3 and still have a good user experience.

Will libraries like webext-redux become non-tenable without a persistent background page? Will users be expected to keep a tab open at all times that is essentially a persistent background page for their extensions?

[wOxxOm]

>  but both of the SaaS extensions that I work on would be not-possible with the proposed V3 changes 

If the only problem is webext-redux then it should be possible to modify webext-redux so it saves/restores its state via chrome.storage.local.

But (as I keep saying around here), if the state is not serializable, the overhead to rebuild it may be so big that the extension will waste CPU/battery just for that. See my comments above about the "complex state" and workarounds to keep the background worker running.

[Inter Net]

My Extension focuses only on the NewTab, so users need to open a new tab and there is a small SaaS they can use, I use React Client State & Indexed DB, do you see any problems in this setup for V3 & maybe for now also? Thanks

[Stephen Bussey]

Yea, I agree with you that the overhead to serialize would be too great for my app. There can be pending screen recordings stored in background (10+ MB easily), or lots of data from the server (more than I'd like to admit). I'm curious to think through it more and also see how this plays out.

My biggest fear is that chrome extension authors will be forced to undertake extensive rewrites. The type of timing where even a year of leeway wouldn't be enough. If you have a 5 year old extension that has been added to and grown over time—and everything works great in V2 manifest—the v3 upgrade may be akin to a framework rewrite.

--

Steve Bussey  |  Co-Founder, Clove 

Solve problems faster with Intelligent Screen Recording 

[wOxxOm]

>  My Extension focuses only on the NewTab, so users need to open a new tab and there is a small SaaS they can use, I use React Client State & Indexed DB, do you see any problems in this setup for V3 & maybe for now also?  

Assuming you use the persistent background script mostly/only to persist the state and use it in newtab, it all depends on how big/complex the state is. If it's relatively simple and serializable then you can probably even remove the background script altogether and just save/restore the state in the newtab script via chrome.storage.local. But, if the state is complex as described in my comments above then you'll have a problem and will have to use the lame workarounds I mentioned to avoid rebuilding it each time.

[Inter Net]

It is really hard for me to understand what kind of state we are talking about here, The state I use in my extension is only client-side (javascript) state and doesn't need to be persistent, the state gets only filled when the user uses the newTab, does it still matter?

[wOxxOm]

> It is really hard for me to understand what kind of state we are talking about here.

It's data stored in js variables. You can see the wiki article for more info.

> The state I use [...] doesn't need to be persistent

Then you're not affected by ManifestV3's lack of a persistent background script.

[Simeon Vincent]

Hey all,

I lost track of this thread (and a few others) but I'm back! At least on this one!

Before I get into specific replies, I wanted to make a general note that I think we've focused too much in this thread on performance as a motivation for the move to service workers. Performance is part of, but far from the whole story. Other major considerations that drove this decision include closer alignment with the web platform, cost of maintaining extension-specific capabilities, and a broader shift from imperative to declarative capabilities. I hope I don't sound like a broken record, but MV3 is a rethinking of Chrome's extension platform. We're taking steps that make sense in the context of a long-term vision for browser extensions.

At least I think they do. If you don't, please ask questions and as always I'll do my best to clarify.

The problem I have with MV3 is that its proponents claim without any tangible proof the persistent use case is non-existent or negligible. - wOxxOm

I'm sorry I've given that impression. I don't think any of us believe "the persistent use case is non-existent or negligible". It's certainly worth consideration; that's why we keep talking about it. I think a more accurate summary of our position is that while there are extensions that benefit from or need persistent background pages today, they can be adapted (possibly with additional platform changes) to deliver comparable experiences using the short-lived, event-based model of service workers. In cases that can't be adapted, we want to understand why so we can explore mitigation strategies that enable these use cases without having to support full persistent pages.

For example, password managers have called out that standard service workers don't allow for temporary storage of "crucial application secrets". In response, we're considering introducing a storage API that holds values in memory across service worker restarts (crbug.com/930235). Depending on how the design process goes, this mechanism may also be viable as a general state cache or value storage mechanism.

Will libraries like webext-redux become non-tenable without a persistent background page? - Stephen

This is the first time I've encountered webext-redux and I've only given their README a quick read so I may have missed something. That said, it looks like the current implementation of this library will not work well with service workers, but I think it's well positioned to abstract away and encapsulate the implementation details of persisting an extension state's.

My biggest fear is that chrome extension authors will be forced to undertake extensive rewrites. … the v3 upgrade may be akin to a framework rewrite - Stephen

IMO the "framework rewrite" framing is apt. MV3 is the largest set of changes we've made to Chrome's extension platform since its introduction. I don't think it's quite as extensive as, say, the transition from Angular 1 to Angular 2, but I expect it will take some work for most extensions to transition and that it will not impact all extensions equally. 

Cheers,

Simeon - @dotproto

Developer Advocate for Chrome Extensions

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b3a81a4d-5a9a-43c7-b46d-7214ec37fe63n%40chromium.org.

[wOxxOm]

>  I don't think any of us believe "the persistent use case is non-existent or negligible".  

It's not about believing, this is what the facts are saying. The fact that MV3 removed the persistent background scripts is unequivocally saying that they're negligible according to MV3 proponents.

[Inter Net]

Thanks, good to know, but why I see people talking so much about  chrome.storage.local, I would love to use IndexedDB in my chrome extension but I see nobody talking about it so much for extension development, is it ok to use?

[wOxxOm]

>  I would love to use IndexedDB in my chrome extension but I see nobody talking about it so much for extension development, is it ok to use?  

It's perfectly okay to use it and sometimes there is no alternative e.g. if you want to store ArrayBuffer efficiently. It's just too advanced for most use cases and its internal implementation in the browser is more complicated so it can be broken more easily which recently happened and there was a wave of extensions losing all their data in IndexedDB, https://crbug.com/899446.

[wOxxOm]

I see the official blog is still making the same unsubstantiated claims that are actually exaggerations bordering on lies:

>  persistent background pages, which remain active in the background and consume system resources regardless of whether the extension is actively using them  

No, usually a persistent background page is just idling, doing nothing. Yes, it occupies 20-50MB of RAM, sometimes more, but that's just a fraction of a typical modern web page so the point about it consuming system resources is an exaggeration and the bit about "active in the background"  would apply only to rare cases when the extension has a bug or it was written by a clueless author, which means such problem affects only a negligible amount of users typically. Extensions don't do anything at all once they've registered event listeners normally. Either way, extensions are a part of the browser so it's only natural to allocate this tiny bit of RAM to keep them ready to start with zero delay so they can augment and extend the browser seamlessly like a so-called "native application" is supposed to do.

> service workers are ephemeral [which] allows Chrome to lower overall system resource utilization since the browser can start up and tear down service workers as needed.

This is a common misunderstanding shared by a lot of web developers who don't understand the specifics of extensions. Apparently, the PR team is trying too hard to find something goodish and blow it up to justify ManifestV3 changes. Let's look at what really happens when a background service worker of an extension starts. We'll be using chrome://tracing, devtools profiler, and simple performance.now() timing.

1. A new process for JS environment is created and a V8 snapshot with standard JS built-ins is initialized. That's 50-100ms already.
2. The extension background scripts are parsed, compiled, executed. Depending on extension that would be 10 - 500ms, typically 100ms. Chrome doesn't cache extension scripts to avoid potential privilege escalation via side-channel attacks so each time the scripts are parsed and compiled anew.
3. The extension initializes and restores its state.  Depending on extension that would be another 10 - 500ms, typically 100ms.

How bad is it?

It's 70-1000ms (typically 100-200ms) of super intense activity with nearly 100% CPU utilization in the extension process and this happens each time the background worker is needed. For many extensions that react to user activity (like page navigation when the user clicks a link) this could happen each minute or hundreds of times a day. The amount of system resources burnt by starting up these extensions might be millions of times bigger than passive idling of the persistent background pages that don't do anything "active in the background" but run only a small amount of code in the idling event listeners when an event occurs.

> Second, we are moving to a more declarative model for extension APIs in general. In addition to security benefits, this provides a more reliable end-user performance guarantee across the board by eliminating the need for serialization and inter-process communication. The end result is better overall performance and improved privacy guarantees for the vast majority of extension users.

Again, an unsubstantiated claim and a huge exaggeration aimed at people who don't have a lot of experience in programming. The real benefit will be negligible, like 0.01%, for almost every extension in almost every usage scenario except a few extremely rare cases where serialization and IPC become noticeable.

Back to the problem of restarting the extension too often. It is immediately obvious to anyone who understands how computers work but it's only recently that I've encountered the first public evidence that at least one Chromium developer understands it too, see https://crrev.com/c/2510431. It's good seeing practical-minded people making practical decisions, isn't it? Now I wonder is it too much to hope for the PR team to stop the blatant propaganda about how good ManifestV3 will be for everyone? Because it won't be. The benefits will be negligible in most cases, like in 99% of cases. Admittedly, the downsides will be also rare but for many extensions and usage scenarios there'll be no way to provide meaningful experience. And for what? To reiterate, the reasons given so far publicly are all unsubstantiated claims or exaggerations.

[Jackie Han]

My thoughts and suggestions on persistent background pages:

Service worker is not suitable for some special scenarios and use cases, no matter now or in the future. Many people have given examples in the past, e.g. DOM API, play sound, timer less than 1 minute, etc. So I personally want to keep this technology. But I know if developers don't use it properly, they could waste system resources. I think persistent background pages like headless chrome pages, it should not have too much maintenance burden, so the following is only from the perspective of system resource management.

Suggestion 1: Manual review prior to publish

Like current permissions and privacy review process, developers need to give a reasonable reason to use it. This can reduce unnecessary use.

Suggestion 2: Limit resource usage

Because persistent background page is a long time running program, it will be troublesome if it has a memory leak issue. Typically, it takes a lot of time for developers to resolve memory leak issue. Like "Protecting against resource-heavy ads in Chrome", I think browser can heuristically limit resource usage of persistent background page. For example, If it uses too much cpu or the memory usage continues to increase and exceeds a certain threshold, browser can limit it or reload it some times, and finally disable it. Most well-implemented extensions should not have this problem.

Hope the above suggestions can keep this technique while avoiding its problems.

On Fri, Dec 11, 2020 at 2:31 AM wOxxOm <wox...@gmail.com> wrote:

I see the official blog is still making the same unsubstantiated claims that are actually exaggerations bordering on lies:

>  persistent background pages, which remain active in the background and consume system resources regardless of whether the extension is actively using them  

No, usually a persistent background page is just idling, doing nothing. Yes, it occupies 20-50MB of RAM, sometimes more, but that's just a fraction of a typical modern web page so the point about it consuming system resources is an exaggeration and the bit about "active in the background"  would apply only to rare cases when the extension has a bug or it was written by a clueless author, which means such problem affects only a negligible amount of users typically. Extensions don't do anything at all once they've registered event listeners normally. Either way, extensions are a part of the browser so it's only natural to allocate this tiny bit of RAM to keep them ready to start with zero delay so they can augment and extend the browser seamlessly like a so-called "native application" is supposed to do.

> service workers are ephemeral [which] allows Chrome to lower overall system resource utilization since the browser can start up and tear down service workers as needed.

This is a common misunderstanding shared by a lot of web developers who don't understand the specifics of extensions. Apparently, the PR team is trying too hard to find something goodish and blow it up to justify ManifestV3 changes. Let's look at what really happens when a background service worker of an extension starts. We'll be using chrome://tracing, devtools profiler, and simple performance.now() timing.

1. A new process for JS environment is created and a V8 snapshot with standard JS built-ins is initialized. That's 50-100ms already.
2. The extension background scripts are parsed, compiled, executed. Depending on extension that would be 10 - 500ms, typically 100ms. Chrome doesn't cache extension scripts to avoid potential privilege escalation via side-channel attacks so each time the scripts are parsed and compiled anew.
3. The extension initializes and restores its state.  Depending on extension that would be another 10 - 500ms, typically 100ms.

How bad is it?

It's 70-1000ms (typically 100-200ms) of super intense activity with nearly 100% CPU utilization in the extension process and this happens each time the background worker is needed. For many extensions that react to user activity (like page navigation when the user clicks a link) this could happen each minute or hundreds of times a day. The amount of system resources burnt by starting up these extensions might be millions of times bigger than passive idling of the persistent background pages that don't do anything "active in the background" but run only a small amount of code in the idling event listeners when an event occurs.

> Second, we are moving to a more declarative model for extension APIs in general. In addition to security benefits, this provides a more reliable end-user performance guarantee across the board by eliminating the need for serialization and inter-process communication. The end result is better overall performance and improved privacy guarantees for the vast majority of extension users.

Again, an unsubstantiated claim and a huge exaggeration aimed at people who don't have a lot of experience in programming. The real benefit will be negligible, like 0.01%, for almost every extension in almost every usage scenario except a few extremely rare cases where serialization and IPC become noticeable.

Back to the problem of restarting the extension too often. It is immediately obvious to anyone who understands how computers work but it's only recently that I've encountered the first public evidence that at least one Chromium developer understands it too, see https://crrev.com/c/2510431. It's good seeing practical-minded people making practical decisions, isn't it? Now I wonder is it too much to hope for the PR team to stop the blatant propaganda about how good ManifestV3 will be for everyone? Because it won't be. The benefits will be negligible in most cases, like in 99% of cases. Admittedly, the downsides will be also rare but for many extensions and usage scenarios there'll be no way to provide meaningful experience. And for what? To reiterate, the reasons given so far publicly are all unsubstantiated claims or exaggerations.

--

Jackie