Remove the service worker and ui.USE_SERVICE_WORKER option

[silverwind]

We don't really gain anything from it except the client-side caching which is a problem better solved on HTTP level. Gitea is not a PWA and will not do anything useful in a offline scenario without having access to the server.

This should also resolve issues seen with the serviceworker interfering on SSE requests.

The only API we can not use without a service worker is push notifications while the "app" is closed but the more established HTML Notification API will be a alternative.

Fixes: #11092
Fixes: #8056
Fixes: #7372

[zeripath]

Probably this needs more than just two approvals

[CirnoT]

Might considering marking this as breaking; I'm sure people that actively use Gitea as PWA (as much as it isn't meant to be) would consider it as such.

[jolheiser]

I wonder if there is any way that this could be added back manually (without code change) for those that want it, through custom content or something similar.
I may try to play with it and add docs or contrib if this gets merged.

[6543]

plreace resolve conflict

[lunny]

should we change this also?

[lunny]

Why not just change the default option to false?

[CirnoT]

Why not just change the default option to false?

That means we would still have and support a broken configuration; specifically with SSE request being killed by SW

[silverwind]

I'm unsure whether to go ahead because SW cache may be more reliable than HTTP-based caches. It should have a performance advantage overall:

https://stackoverflow.com/a/47972445/808699
https://developers.google.com/web/showcase/2016/service-worker-perf

Regarding the SSE issue, I'm not sure if SW is really the source of the issues. We have it configured as a static list of resources to cache and non-matches should always hit the network.

[silverwind]

I'll close this and follow up with a better approach to the SW (which in itselfs still seems valuable to keep for performance) using workbox with destination-based caching. This will also free us from the burden of having to manually keep that file up to date.

[CirnoT]

We have it configured as a static list of resources to cache and non-matches should always hit the network.

But the request that hits network is intercepted by SW, and SW are not supposed to be working forever; hence Firefox kills it after 30s, breaking SSE.
https://stackoverflow.com/questions/29741922/prevent-service-worker-from-automatically-stopping
https://bugzilla.mozilla.org/show_bug.cgi?id=1378587

There really should be some way to mark SSE connection so that it is never intercepted by SW in the first place, but it seems there isn't and SW dying closes SSE connection.

Do we really need to additionally burden Gitea with libraries designed for offline usage, such as workbox? They explicitly say

JavaScript Libraries for adding offline support to web apps

As far as I am concerned; and you confirmed, Gitea isn't such and won't be.

[silverwind]

As discussed, the SSE issue should be because the SW unconditionally handled all requests. Should be fixed in #11538 which only intercepts a subset of requests.

[silverwind]

Do we really need to additionally burden Gitea with libraries designed for offline usage, such as workbox

I'd say it's justified because when using serviceworkers, we can guarantee at least some degree of caching which is important for performance because we do have some large assets (monaco) that really benefit from it. The current workbox implementation is only 28kB, so very lightweight.