Use cases that are not well served by service workers

[dotproto]

Near the end of the 2021-08-19 meeting we briefly discussed (but didn't capture) the idea of collecting background page use cases and design patterns that are not well served by service workers. My hope is that by collecting these use cases in a well known location, community members and browser vendors we will be able to more concretely discuss the challenges posed by this new background context and explore potential solutions.

Please use this issue to link to use use cases that are impossible to accomplish with or not well supported by service workers. If you'd like to report a new use case, please create a new issue and reference this one.

Use cases

Specific ways that background pages are used that cannot be accomplished with a service worker.

• HTML/XML parsing
  • Issue 1056354: Add support for parsing XML and HTML documents to Manifest V3
  • Issue 1051597: Extension Manifest V3 support for SingleFileZ and similar extensions
• Background page interaction
  • Issue 1128240: Background page loading & manipulation in service worker browser extensions
• Audio playback
  • Issue 1131236: Playing audio in service worker-based browser extensions
• Clipboard access
  • Issue 1160302: Cannot read clipboard from service worker in a MV3 chrome extension
• Blob URLs
  • Issue 1051597, comment #5+
• Requesting file:-scheme resources (aka file:// URLs)
  • Issue 1051597, comment #12+ – Discussion of file resource request limitations in Fetch
• WebRTC streams
  • Extension "Snowflake" Create RTCPeerConnections in workers webrtc-extensions#77 (comment)
  • Issue 1207214: RTCDataChannel for ManifestV3
• WebSockets
  • chromium-extensions: MV3 Service Workers Don't Support Websocket
  • Create RTCPeerConnections in workers webrtc-extensions#77
• Native messaging
  • Issue 1152255: ServiceWorker is shut down every 5 minutes for manifest V3 extension
• Wasm
  • Issue 1173354: wasm does not work in extensions manifest v3

Other discussions

• [Manifest V3] WebExtensionWorker instead of Service Worker #11
• clarification request: what happens when a MV3 SW is shut down before answering a message #16
• request: don't standardize around lowest common denominator platform (e.g., mobile) #25
• Proposal for Manifest V3: add permission allowing a background script to be persistent #44
• Requiring Service Workers for extensions fundamentally user hostile #51
• Considerations for WebAssembly runtime #39

[mingyaulee]

One additional use case for background service instead of service worker is the use of web assembly.
This is related to the issue I raised in #39.

[cuylerstuwe]

Not added here is extension-driven behavior from an external source.

This includes user-driven input coming from an outside (related) desktop/cloud app via WebSockets or Native Messaging Hosts.

Their connections need to persist indefinitely in order to work effectively.

[cohosh]

Hey! I've just shared a use-case where we need access to RTCPeerConnection for service workers in order to upgrade to using v3 manifests here: w3c/webrtc-extensions#77 (comment)

[avi12]

Another use-case is using FFmpeg via @ffmpeg/ffmpeg, which is using WebAssembly
To provide the best user experience using this module, you need to put it on the background page, which would make it accessible from all of the parts of the extension
Such a background page must also be persistent, as it takes a few seconds until FFmpeg gets initialized; if it isn't persistent, it might get terminated by the browser, thus requiring re-initializing FFmpeg for every user action that would result in FFmpeg processing

[dotproto]

Such a background page must also be persistent, as it takes a few seconds until FFmpeg gets initialized; if it isn't persistent, it might get terminated by the browser, thus requiring re-initializing FFmpeg for every user action that would result in FFmpeg processing

@avi12, from the Chrome team's point of view terminating an unused worker is a feature, not a bug. Can you expand on why reinitializing FFmpeg is a problem? Adding latency to an uncommon operation is understandably undesirable, but so is keeping around an unused JS context.

Is there a specific workflow with an existing extension you can point to?

[dotproto]

@mingyaulee Added a crbug link related to allowing Wasm in MV3 service workers.

@cuylerstuwe, I just added a thread you started on chromium-extensions related to WebSockets and a crbug issue tracking native messaging.

@cohosh Added your link and the related crbug issue

[avi12]

@dotproto

Adding latency to an uncommon operation is understandably undesirable, but so is keeping around an unused JS context.

That's true. However, in CLI apps like FFmpeg, which can only do one job at a time (which is particularly true for the WebAssembly version), if the job takes too much time (depending on the operation and the size of the files you work with), it might get terminated mid-way through, due to the limited 5-minute lifespan of an extension's Service Worker

Is there a specific workflow with an existing extension you can point to?

Right now, I'm working on this extension

[avi12]

Another use-case is when needing to download files, which, if need to be initiated in the current Service Worker, will have 2 issues:

1. A Service Worker's lifespan is up to 5 minutes, If you need to download files that would take more than 5 minutes, it would be disrupted mid-way
2. If you find yourself needing to use the Fetch API (like in my extension), making the download cancellable is important for a good user experience. The only way to cancel a Fetch process is by using AbortController's AbortSignal, which so happens to use the DOM

[Jack-Works]

A Service Worker's lifespan is up to 5 minutes, If you need to download files that would take more than 5 minutes, it would be disrupted mid-way

Try Background fetch?

[avi12]

That's an interesting option
However, my extension that I linked above also needs to run FFmpeg on the background, so I don't think the Background Fetch API will be enough for my use-case

[cuylerstuwe]

In a world where RAM is plentiful and tends to be cheaper/easier to upgrade than CPUs, it’s pretty odd that the current Chrome team would essentially prioritize memory over CPU cycles. This is especially weird since Chrome has historically performed better than Firefox almost every synthetic and real-world benchmark, at the cost of higher RAM use.

…

On Fri, Sep 3, 2021 at 2:27 PM Simeon Vincent ***@***.***> wrote: Such a background page must also be persistent, as it takes a few seconds until FFmpeg gets initialized; if it isn't persistent, it might get terminated by the browser, thus requiring re-initializing FFmpeg for every user action that would result in FFmpeg processing @avi12 <https://github.com/avi12>, from the Chrome team's point of view terminating an unused worker is a feature, not a bug. Can you expand on why reinitializing FFmpeg is a problem? Adding latency to an uncommon operation is understandably undesirable, but so is keeping around an unused JS context. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4MEMARJGBYH37GEZO2ILTUAE4SVANCNFSM5DJTXWDQ> .

[tregagnon]

@dotproto I think crbug 893175: Request for an API to specify Light and Dark Mode Icons should be added to the list

The Service Worker does not have window.matchMedia() which was used by Extensions to identify if the OS was in Dark/Light mode. We need the action.setIcon() API to be extended so Light/Dark icons can be set.

Defining those Light/Dark icons in the Manifest only is insufficient for extensions like Dashlane, which also uses the icon to indicates if the user is authenticated or not.

[ghostwords]

What about the general mismatch of webpages having user-defined lifetimes with Service Worker-based extensions having arbitrarily limited lifetimes (five minutes in Chrome at this time)?

The user may be relying on extension-provided functionality on some webpage when the extension's SW gets shut down. Even if the SW were to get restarted in response to content script messages, shutting down and restarting a SW is inherently a waste of resources. The additional delay caused by SW startup will break use cases that depend on speedy messaging between the content script and the background page (for example, an extension that dynamically modifies the right-click menu based on type of clicked element). Furthermore, after a SW restart, content scripts may have stale configuration data and won't work properly without additional message passing or a page reload.

If content scripts were to also get reloaded along with the SW, this would introduce clear usability issues, where the user is in the middle of some extension-facilitated workflow that suddenly stops working.

[tophf]

Another blocker: https://crbug.com/1219164 - ability to create nested workers.

BTW, the title should reflect that these use cases are currently impossible to implement in a service worker, please don't use the euphemistic language such as "are not well served".

[gildas-lormeau]

It's not possible to use chrome.i18n.getMessage to set the label of the action button or the entries in the context menu.

[capaj]

Safely storing confidential information for the duration when browser is running.

Chrome docs on storage api explicitly say that:

Yet they explicitly advise to use it to store data which is needed in the service worker:
https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#state

I think @bitwarden relies on this when they store the master password inside backgroundPage so that the user doesn't have to put it in every time when they open the Popup.

[gorhill]

Please use this issue to link to use use cases that are impossible to accomplish with or not well supported by service workers.

A use case not possible with a worker, "Bug 1580254: Support CSS selector validation API from a service worker":

Removing access to a DOM would currently break uBlock Origin (“uBO”). uBO uses a DOM element to validate plain cosmetic filters[4] – which are essentially CSS selectors. Having access to the DOM to validate plain cosmetic filters allow uBO to detect and discard or further process invalid cosmetic filters.

[...]

[ghostwords]

Requesting file:-scheme resources (aka file:// URLs)

The Fetch API is also unable to retrieve chrome:// resources apparently, something you can do now with XMLHttpRequest.

[tophf]

Dynamic import of scripts in a service worker is only partially implemented and prohibitively convoluted.

https://crbug.com/1198822

• No dynamic import(), also no script elements since there's no DOM.

• Only importScripts is supported.

  • it imports solely into the global scope, which means you would need a module management system i.e. use webpack (and similar systems) or find some service-worker-compatible library or write one yourself;
  • it's synchronous, which adds considerable internal overhead to stop the execution environment for the duration of reading the file. It's essentially the same as the ancient synchronous blocking XMLhttpRequest, deprecated and strongly discouraged for many years.

• We have to duplicate importScripts explicitly inside the install event listener of the service worker for every script we will ever import later. The same will be necessary for the dynamic import() when it's implemented.

And there's also a foundational issue of an understandable reluctance in the service worker spec group to provide WebExtensions-specific improvements, further exacerbated by an understandable reluctance of the browser developers (Chromium extensions team, specifically) to provide non-standard exceptions in a service worker as it would add maintenance burden on them and introduce fragmentation of otherwise solid technology. Allowing the dynamic import of scripts without the need to pre-import them in the install event listener (all importable scripts are already local in an extension) is an example of such problem as well as the ability to control the lifetime of the service worker or create blob: object URLs, and many more problems introduced by the premature decision to switch to service workers in ManifestV3.

[avi12]

from the Chrome team's point of view terminating an unused worker is a feature, not a bug. Can you expand on why reinitializing FFmpeg is a problem?

@dotproto Assuming the user is willing to wait a few seconds every time he wishes to use the FFmpeg functionality, the Service Worker will still get terminated after 5 minutes, making mv3 a huge limitation

[bershanskiy]

setTimeout and setInterval (though frowned on) have many unavoidable use cases and cannot be relied upon in an extension Service Worker because they're cleared when it suspends.

In my experience, extensions can combine setTimeout/setinterval with alarms to achieve almost any desired outcome. Specifically, use setTimeout/setinterval for short intervals less than 5 minutes (arbitrary lifetime limit at some point enforced by Chromium) and set regular alarms for events more than a minute apart. Some use cases for short setTimeout/setinterval do not even require persisting beyond service worker lifetime: in-memory cache with regular timed clenups, time limits for lengthy operations initiated by service worker itself, etc. Could you please describe your specific use case and perhaps I can describe how to do it with setTimeout/setinterval and alarms?

[bershanskiy]

Another use case not served by service workers is language change detection: language and languages live under navigator so are accessible from service workers, but oddly enough languagechange event is delivered to window. So extension backgrounds can detect the current language but can not react to changes (without regular pulling, of course).

[tophf]

extensions can combine setTimeout/setinterval with alarms to achieve almost any desired outcome

@bershanskiy, this won't work in Chrome where 1) the SW lives for just 30 seconds since the moment it was started, 2) its lifetime is not prolonged by new chrome events, which is a nasty regression compared to MV2 event pages, 3) chrome.alarms is throttled to 1 wake-up per minute. The only way it can work is if we use a nativeMessaging host to keep the SW alive or constantly re-open ports from other tabs, which is not guaranteed to be open and requires broad host permissions.

[carlosjeurissen]

Another use case not served by service workers is language change detection: language and languages live under navigator so are accessible from service workers, but oddly enough languagechange event is delivered to window. So extension backgrounds can detect the current language but can not react to changes (without regular pulling, of course).

In serviceWorkers you can listen for languagechange using:

self.addEventListener('languagechange', console.log);

or simply:

addEventListener('languagechange', console.log);

This has been tested in Mozilla Firefox, Google Chrome and Opera with success.

[DavidJCobb]

Service workers will lead to inconsiderate and wasteful bandwidth usage. Consider, for example, an extension that allows a user to manage or search through personal content or collections stored on a website (e.g. "favorites," "followers," "lists," etc.) in ways that a site does not normally offer -- perhaps a site with relatively minimal APIs, as opposed to the Internet's major corporate-funded platforms; in essence, a site that you have to scrape in order to extend.

The polite way to implement something like this would be to cache data in-memory whenever possible (possibly clearing that cache after enough time spent idle or off-site) to minimize how many redundant requests have to go over the network during a single browsing session. However, you can't cache anything using service workers. The 1MB storage in chrome.storage.session is tiny; it'd be pathetically small even if we could store space-efficient binary data e.g. DataView, which, of course, we can't. The other storage areas are inappropriate for caching during a single browsing session, and may have privacy implications (e.g. for incognito browsing) as well. (There would also be logistical difficulties in taking what's supposed to be a session-specific cache and placing it in persistent storage. At minimum, you'd have to go to the trouble of wiping your jury-rigged cache onStartup and rejecting/deferring all queries until that's complete. With how patchy WebExtensions APIs have been in my experience, I have zero confidence that trying this wouldn't lead to some huge unexpected obstacle.)

That leaves the impolite way: repeatedly bombard the website with requests for the same information you just asked for three minutes ago. Cache nothing; precompute nothing; optimize nothing; write rampantly wasteful code, because it's the only thing you're allowed to write.

The performance cost for the network requests can be larger than one might expect. I've been privately developing and testing some WebExtensions and working on getting them release-ready, and some of the sites I've been making add-ons for have anti-botting/anti-DDoS measures. Slamming them with tons of rapid-fire redundant requests is a great way to get rate-limited and receive a slew of 503s. If you need to scrape, say, a few dozen pages to gather up and preload metadata about a user's saved content, you might have to throttle those requests to ensure reliability. That's fine when it's information that you can query just once or twice, store in a background page, and then reuse throughout the rest of a browsing session (perhaps manually updating the in-memory copy without extra network requests if the user makes changes through the website). With service workers, however, you can't usefully cache anything, so that throttling ends up adding a substantial delay to a WebExtension's reactivity, because now the user has to wait on it every time the service worker wakes up.

[radiolondra]

It seems to me (tested) that calling the function below when any service worker starts, keeps the service worker up forever (that is, it doesn't go to sleep anymore).
Question: Is this (another) Chrome bug or I found a way to keep a service worker alive forever?

-------------------------------------------->>> Code Description
The function (StayAlive), inside the service worker, connects to a named port and tries to send a message through it to a nonexistent listener (so it will generate errors) when the service worker starts.

While doing this, SW is active and running (ok, it has something to do, that is, it has to send a message through a port, but this is my doubt about a possible Chrome bug, because the connect() is started by the service worker itself, not by some external tab/app/extension/whatever... ok, lets go on with the code description).

Because noone is listening, it generates a (catched and logged) error (in "onDisconnect" port event) and terminates.

But after 25 secs it does the same iter from start, keeping SW active forever.

Note: To perform reliable tests remember to not open any DevTools page. Use chrome://serviceworker-internals instead and find the log (Scope) of your test extension ID.

This is the code:

// In ServiceWorker.js
// -------------------
// Forcing service worker to stay alive by sending a "ping" to a port where noone is listening
// Essentially it prevents SW to fall asleep after the first 30 secs of work.

const INTERNAL_STAYALIVE_PORT = "Whatever_Port_Name_You_Want"
var alivePort = null;
...
// Call the function at SW start
StayAlive();
...

async function StayAlive() {
    var lastCall = Date.now();
    var wakeup = setInterval( () => {
        
        const now = Date.now();
        const age = now - lastCall;
        
        console.log(`(DEBUG StayAlive) ----------------------- time elapsed: ${age}`)
        if (alivePort == null) {
            alivePort = chrome.runtime.connect({name:INTERNAL_STAYALIVE_PORT})

            alivePort.onDisconnect.addListener( (p) => {
				if (chrome.runtime.lastError){
					console.log(`(DEBUG StayAlive) Disconnected due to an error: ${chrome.runtime.lastError.message}`);
				} else {
					console.log(`(DEBUG StayAlive): port disconnected`);
				}

				alivePort = null;
			});
        }

        if (alivePort) {
                        
            alivePort.postMessage({content: "ping"});
            
            if (chrome.runtime.lastError) {                              
                console.log(`(DEBUG StayAlive): postMessage error: ${chrome.runtime.lastError.message}`)                
            } else {                               
                console.log(`(DEBUG StayAlive): "ping" sent through ${alivePort.name} port`)
            }
            
        }         
        //lastCall = Date.now();
               
    }, 25000);
}

[cacosandon]

If you came here looking for recording video/audio solution for MV3, you can use this example: https://github.com/wireworks-app/chrome-screen-recording

[Pauan]

I have created an extension which helps the user to manage tabs more easily.

It displays the user's tabs in a vertical list, it allows for organizing tabs with labels, it allows for searching through tabs, it allows for bulk operations on many tabs, etc.

It's designed for users who have a lot of tabs (hundreds, or potentially even thousands of tabs).

Because it needs to process a lot of tabs, and it needs to process those tabs quickly, it keeps the tab data alive in RAM with a persistent background page.

When a new tab event happens (because a tab was closed, or opened, or moved, etc.) it can very quickly process the event, because all of the tab data is kept in RAM.

This is a very natural and efficient design, and it mimics what the browser itself does (the browser has its own C++ representation of the tabs which is always kept available in RAM).

However, this is incompatible with service workers, because service workers can never be persistent.

Re-processing potentially thousands of tabs on every tab event is unacceptable for performance, it will slow down the browser and lead to a bad user experience.

[Pauan]

I have created a Chrome extension which automatically bets on the saltybet.com website (automatic betting bots are allowed by the SaltyBet rules).

In order to make the bets, it needs to look at past historical data. There is a LOT of historical data (258 MB of data).

This data is loaded and processed inside of a persistent background page. This processing takes about 39 seconds.

This is acceptable because the data only needs to be loaded one time, and then it can be reused over and over again for each match.

However, this is incompatible with service workers, because service workers cannot be persistent.

Re-loading the data over and over again is completely 100% unacceptable for performance.

Any use case that requires loading or processing large amounts of data is incompatible with service workers.

For example, if somebody wanted to create a folding@home extension for Chrome, it would not work because it needs to store and process large amounts of data.

[Pauan]

Cryptocurrency wallets are incompatible with service workers.

Cryptocurrency requires a lot of expensive computations (to generate keys, download the blockchain, etc.). This computation can potentially take several seconds, or even minutes.

Because the computation is so expensive, cryptocurrency extensions must cache the computation so that it only needs to be done one time.

However, because service workers cannot be persistent, that means it cannot cache the computation.

Here is an example:

https://chrome.google.com/webstore/detail/leo-wallet/nebnhfamliijlghikdgcigoebonmoibm

Because of the lack of persistent background pages, that extension opens a new tab and then does all of its computation inside of that tab.

So the user must keep that tab open at all times in order to use the extension.

This is obviously a completely unacceptable user experience.

Persistent background pages do not have that problem, because it can simply cache the computation inside of the (invisible) background page.

With persistent background pages, the extension could use a browser action popup for its UI.

But because service workers are not persistent, the extension cannot use a browser action popup, it must use a browser tab, which is an inferior user experience.

Any extension that requires in-memory caching of expensive computations is incompatible with service workers.

As time goes on, more extensions will start to abuse tabs as a substitute for persistent background pages, requiring the user to keep the tab open at all times in order for the extension to function.

[alanhkarp]

Can you use session storage? That's what I'm using for a very small amount of data. I'm doing it with my fingers crossed because I haven't found a definitive statement that what's in session storage never appears on disk.

…

-------------- Alan Karp

On Fri, Oct 13, 2023 at 8:01 PM Pauan ***@***.***> wrote: Cryptocurrency wallets are incompatible with service workers. Cryptocurrency requires a lot of expensive computations (to generate keys, download the blockchain, etc.). This computation can potentially take several seconds, or even minutes. Because the computation is so expensive, cryptocurrency extensions must cache the computation so that it only needs to be done one time. However, because service workers cannot be persistent, that means it cannot cache the computation. Here is an example: https://chrome.google.com/webstore/detail/leo-wallet/nebnhfamliijlghikdgcigoebonmoibm Because of the lack of persistent background pages, that extension *opens a new tab and then does all of its computation inside of that tab*. So the user must keep that tab open at all times in order to use the extension. This is obviously a completely unacceptable user experience. Persistent background pages do not have that problem, because it can simply cache the computation inside of the (invisible) background page. With persistent background pages, the extension could use a browser action popup for its UI. But because service workers are not persistent, the extension cannot use a browser action popup, it must use a browser tab, which is an inferior user experience. Any extension that requires caching of expensive computations is incompatible with service workers. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFAT44KNPBDQZ7OIQ435HLX7H57HANCNFSM5DJTXWDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Pauan]

Can you use session storage? That's what I'm using for a very small amount of data.

No, cryptocurrency wallets take security VERY seriously, it is unacceptable to have even the tiniest chance of private secrets leaked. Very large amounts of money are involved.

Anything private must be kept exclusively in memory, which means the extension must use in-memory caching with persistent background pages (or abuse tabs as a substitute for persistent background pages).

Even if sessionStorage was guaranteed to be in-memory only, it can only store a small amount of data, so it cannot support every use case.

Also, sometimes the cryptocurrency calculations take longer than 5 minutes, which means Chrome will kill the service worker, which obviously breaks everything. Caching cannot solve that problem.

So any extension that needs to run a very expensive computation (which takes longer than 5 minutes) is incompatible with service workers.

[tophf]

Note that session storage leaks into the content script context in Chrome, which can be hacked by a web page via a side channel attack as they share the same physical process.

[radiolondra]

You could give a look to this:
https://stackoverflow.com/questions/66618136/persistent-service-worker-in-chrome-extension/75082732#75082732
https://github.com/radiolondra/ServiceWorker-Highlander
https://github.com/radiolondra/ServiceWorker-Highlander-DNA
I use Highlander to make background worker persistent forever in my MV3 browser extensions. It works.
I already have talked about it here: #72 (comment)
when I was starting to work on it.

[alanhkarp]

In the bug report, the content script has to set up a listener on chrome.storage for the it to learn what's in session storage. I don't do that. Does that mean I'm safe?

…

-------------- Alan Karp

On Sat, Oct 14, 2023 at 3:13 AM tophf ***@***.***> wrote: Note that session storage leaks into the content script context <https://crbug.com/1342046> in Chrome, which can be hacked by a web page via a side channel attack as they share the same physical process. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFAT4ZS23IMW7FFWOXRNCDX7JQWFANCNFSM5DJTXWDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Pauan]

@alanhkarp Does that mean I'm safe?

Maybe, maybe not. It's possible for malicious code to gain access to the content script (either through a browser bug, or XSS, or something like Spectre).

So even if you don't set up an event listener, if the malicious code is able to set up an event listener then it is vulnerable.

[alanhkarp]

Thanks. I feel a little better. That kind of vulnerability would be pretty devastating to a lot more than my extension and would be pretty hard to protect against anyway. If you could change the code of my content script, you could just ask my service worker for all its secrets, and it would just send them to you.

…

-------------- Alan Karp

On Mon, Oct 16, 2023 at 4:12 PM Pauan ***@***.***> wrote: @alanhkarp <https://github.com/alanhkarp> Does that mean I'm safe? Maybe, maybe not. It's possible for malicious code to gain access to the content script (either through a browser bug, or XSS, or something like Spectre <https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>). So even if *you* don't set up an event listener, if the malicious code is able to set up an event listener then it is vulnerable. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFAT4YQ6LCP64UDNW635VDX7W5MZAVCNFSM5DJTXWD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZWGU2DAOBUGUZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[erosman]

I came across a simple issue which has become complicated in the background service worker.

'prefers-color-scheme' detection in Chrome background service worker

window.matchMedia('(prefers-color-scheme: dark)').matches
// Uncaught (in promise) ReferenceError: window is not defined

The complicated chrome.offscreen option isn't optimal when window.matchMedia has to be performed repeatedly to set action.setBadgeBackgroundColor.

[hanguokai]

'prefers-color-scheme' detection in Chrome background service worker ……

This has been discussed several times in Chromium forum, like this. Even in the event page, it also has a problem. That is why it requires a better solution from the browser #229 .

[visionarylab]

The service worker seem to want to minimize battery usage with lesser cpu cycle (service worker die in 5 min) and memory holding.

Some browser vendor might argue, there is ton of other tool for "automation" on web, other than browser, because safety issue (Other UI tools)

1. For memory, with api similar to localstorage, it can be solve by assign limited memory amount to every extension. (Or just hidden the complexity by following options permission.

2. Since permission is the most successful stuff we had to protect everyone, from firefox to android era. Potentially there is a option list from 128MB to 1GB we willing to give to every extension we installed.

• Most user dont use more than 30 extension, it should be ok to micro manage by people. Permission is the only successful way for teaching user's security (modern generation)

[ParticleCore]

Scary to see that even after all this time, the original major issues have yet to be addressed. I'm adding my issue into the mix as well in hopes that it contributes for something #518

[cedricalfonsi]

I would like to bring attention to a challenge we're encountering with service workers in Chrome, specifically their inability to fetch from servers presenting invalid certificates: Error: (failed)net::ERR_CERT_AUTHORITY_INVALID.

This issue is documented in the following Chromium tickets:

• Chromium Issue 40882068
• Chromium Issue 40869181

I want to verify with you if fetching from servers with invalid certificates via the extension service worker will be supported over the long term. Additionally, could employing the offscreen API be a viable temporary workaround for this problem? Any guidance on this approach would be appreciated.