This isn't quite right. Per the Service Worker Security FAQ, Chrome will terminate a service worker after it "has been idle for 30 seconds
15 seconds was the actual measured time. Either way, it's ignoring the pending requests which is the important point.
> you have a window of time for requests to settle and to process their responses
An arbitrary inflexible duration, which isn't sufficient for unpredictable real world conditions as shown in this case. MV3 also doesn't provide an official way to postpone unloading the worker, only the workaround via extension messaging port. And stop saying it's for performance reasons because it's not: restarting the worker is much more costly than keeping an idle process for a minute.
> As a bit of unsolicited feedback, wOxxOm, my main frustrations with your communication style are your tendency to malign those you disagree with and to assign motive to their actions. I don't mean to tone police; you have every right to be frustrated and to vehemently object, but you do not have the right to cast aspersions on others.
Your frustrations, huh. You're new here. Imagine any extension author who has been waiting for something meaningful to happen with the extension API for the last ~5 years. For example, for the team to fix all those reported bugs, to add the features we asked. Of those hundreds reports only a couple are processed each year, but the whole bulk is just left unattended and ignored, periodically some reports are archived because it becomes apparent that no one will deal with them. They're dying and our trust is vanishing.
Now what happened instead is that they're breaking the entire platform by removing the persistent pages with a cherry on top: the blocking webRequest is also removed for non-forced-installed extensions. We the extension authors don't benefit from that. Our users don't benefit from that. You and the team ludicrously exaggerate the bad impact of persistent pages without providing any real measurements performed globally (like these
The only good things added would be Promises (not yet added) and declarativeNetRequest (could be added to MV2).
> The fact that we haven't been convinced that long-lived pages are the right solution for the extension platform does not mean that we ignore or dismiss feedback.
But the team effectively does ignore/dismiss it in the end. This decision was made 6 years ago
or even earlier without any tangible proof based on global metrics. No one in the team has even tried to listen AFAICT.
> I promise you that I personally read and consider as much discussion on this topic as I can and regularly surface these discussions with the extensions team.
Stop taking it personally. You're a cool person and all that, but I don't see what you can change. The team isn't all that bubbly image you painted for me. They're primarily practical people so there are things they just can't do without the team being expanded several times e.g. from a couple of people currently to 5 or 10 people.
> Service workers have drawbacks, yes, but they also have benefits that, frankly, we value more highly than you do.
That's a part of the problem the team creates: the documents/promos they've released are inflating the benefits of service workers while exaggerating the bad effects of persistent background pages. We the extension authors are not retarded. We are not sheep in need of herding. Show us the facts and global measurements or just stop selling the point of improved performance and admit the performance will be almost the same or negligibly better in some cases, negligibly worse in others (here you could mention what to do to avoid that in detail), and rarely much worse (here you need to list the known cases and say what you're doing to solve that). None of the documents say that. Fix that or finally admit that no one actually cares. None of the related reports on crbug get any meaningful attention anymore, and judging by the 5+ trend outlined above they might never get any.
> it seems that you conclude persistent background pictures are the only solution whereas we want to understand the problem space so we can find solutions that work with an event based model.
Any programmer who's not an idealist knows that when performance is concerned one needs measurements, statistics, or a proof-of-concept before making any change, especially a breaking one. The chromium team did neither of those judging by the fact we didn't see the data. The fact that you and the team are unable to even admit the possibility of a case where your assumption is completely wrong is also telling you're either idealistic or just arrogantly thinking your experience/understanding is superior. There are real-life examples shown over the last year here in the groups (uBlock Origin, Tampermponkey/Violentmonkey, Stylus/Stylish) that work much better with a persistent background script, which should be obvious to anyone, who's actually looking at what those extensions are doing. Their authors aren't posting on crbug though because the extensions will be broken by other changes in MV3. There are many other examples I gave that you've dismissed as being theoretical but they are based on real life cases that I observed for the last ~5 years on StackOverflow where I helped on literally thousands of questions that comprise quite a lot of various practical cases.