Closed LifeIsStrange closed 1 year ago
It adds a delay every time the "service worker" is re-initialized. And with MV3 this happens pretty often.
On our side we implemented some mitigations to that issue so it won't be that critical, but anyways, it sometimes happens.
There are ways to resolve this completely. One way would be to change the way cosmetic filters are applied and move them to the "content script" (the one that's executed in the context of a web page).
However, the preferred way would be to wait until Google implements their "offscreen document" proposal as it would allow keeping filtering engine alive in the background.
@ameshkov thank you very much. We'll there's hope then.
"offscreen document"
Any links for this plz?
Edit I guess it's this https://github.com/w3c/webextensions/issues/170
@LifeIsStrange yeah, that's the right link
@ameshkov What about
The bad thing is that this will increase resource consumption of extensions (roughly twice compared to either SW or the old background page) while the missing features are implemented for the service worker context, which realistically will take more than 5 years
This is overly dramatic tbh. But yeah, it's harder and more complicated than with MV2.
There's people saying cosmetic filters in MV3 require (?) a web worker and that the web worker take (?) (or can take) 5 seconds hence the first 5 seconds on pageload will have UI jank because of the delay between cosmetic filters application. Does that hypothetical delay only apply at chrome browser startup? Or for each navigation? Are there technical solutions to this problem? (e.g a cache would make no difference for first page load)