search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
595 stars 56 forks source link

The background page to service worker change may backfire in practice #136

Open wolfspelz opened 2 years ago

wolfspelz commented 2 years ago

While thinking/writing on discord I "discovered" that the move to time-limit background tasks by moving them to service workers (#72) might backfire. I understand that this is a solution for a problem. But it might have unintended consequences. While this is the obvious solution, sometimes people do not react as you expect, and things develop differently. I would like to have your opinion. Maybe I got something wrong.

Any extension that wants to do compute in the background will immediately restart the background task. So, the background task will still run all the time and the change does not help. Others who need a persistent context (to store data, state or maintain a network connection) will also restart the background task AND consume additional resources doing so. In essence: the change does not achieve the desired effect and even hurts performance.

With respect to memory consumption: there might be more worthwhile targets. A typical chrome tasks list of my always open tabs shows the weblin.io extension uses 30 MB and does almost nothing even though it holds user items, avatars and manages a persistent messaging connection. Compare this with chrome core processes (1.1 GB), LinkedIn, Facebook, gmail tabs (300 MB each), and many tabs/extensions between 100 and 300 MB including Google Sheet, Google Analytics, Google Keep, Google Translate. Then tell me that the Manifest V2 extension is a resource hog, that must be dealt with.

chome-taskspng

What do you think?

(Related to the persistent-background-context-for-a-messenger-app issue #133)

cuylerstuwe commented 2 years ago

I agree, but I also think that this is almost so obvious as to not warrant creating a distinct issue for the topic. This backlash against the fundamental problems in MV3 is so widespread that it's easy to find several other issues that essentially complain about the same things.

cuylerstuwe commented 2 years ago

In response to your edit:

I pointed out some similar hypocrisies when Google announced that the in-memory chrome.storage.session API would be limited to 1MB.

Meanwhile, the New Tab Page takes up 40MB of RAM, and if I leave an instance of Gmail open, it holds onto at least around 200MB indefinitely.

These were measured on a totally clean Chrome profile, of course.

"Do as I say, not as I do."