Old version of app being loaded in browser

Ionic Framework
1

We have an app which we deploy as a web app as well as on iOS and Android. A few months ago made a bunch of changes to the app (Ionic 5 to Ionic 6, Capacitor 2 to Capacitor 3, Angular 10 to Angular 13 and a few others) - at this point the version of the app changed from version A to version B.

Having deployed version B we are seeing a strange issue. In Chrome, when the user initially navigates to the app, version A of the app is still being loaded (in the app, the version number is stored in a config.ts file and when the app starts we output the version number to the console). If the user then logs out of the app and back in again version B of the app is always successfully loaded.

So there is some sort of cacheing issue going on here - is there some sort of service worker that loads the app and is still cacheing the old one (or something along these lines)? The files for Version A of the app do not exist on the server and yet they are being loaded - they must therefore be cached somehow? Does anyone have any advice as to what might be going on and what the best fix might be?

2

I guess if you use incognito mode and the issue does not show you can indeed rule out server side

Then you ask the right question regarding service worker - is there one active as you see in devtools? If you unregister the problem is gone?

And then the question how your service worker update routine is implemented - automatically (and when then?)

1 Like
3

I’m not really understanding as don’t really know anything about service workers. We have not implemented any special service worker ourselves so whatever is going on here is the default behaviour for Ionic. If I look in devtools and click on Application I can see a service worker listed (ngsw-worker.js). Is it this service worker that is caching an old version (Version A) or the app ?

4

I had the same issue, after digging around i found that deleteing the .angular folder with all its contents and running npm i, solved the problem.

Screen Shot 2022-08-11 at 9.32.19 AM
Screen Shot 2022-08-11 at 9.32.19 AM700Ă—136 11.1 KB

1 Like
5

Our app is re-built on the AppFlow platform every time we deploy the www files so I don’t think that would help - as anything in that folder would be re-created at build time anyway?

6

You say you have no special service worker configured or you dont have a service worker configured at all?

If there is a service worker active as can be seen in devtools then any point in the past there has been an app deployed under that url with a service worker

And the update behavior is per way that service worker was configured in that previous app deployed under that url

Which can indeed be that the app updates itself suddenly during a user session

Even if you are now deploying an app without service worker

1 Like
7

Thanks @Tommertom - so I’ve just discovered that in version A of the app I have a ngsw-config.json file and in version B I don’t. I’m not really sure why it has been removed. It’s contents in version A are:

{
  "$schema": "./node_modules/@angular/service-worker/config/schema.json",
  "index": "/index.html",
  "assetGroups": [
    {
      "name": "app",
      "installMode": "prefetch",
      "resources": {
        "files": [
          "/favicon.ico",
          "/index.html",
          "/manifest.webmanifest",
          "/*.css",
          "/*.js"
        ]
      }
    },
    {
      "name": "assets",
      "installMode": "lazy",
      "updateMode": "prefetch",
      "resources": {
        "files": [
          "/assets/**",
          "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)"
        ]
      }
    }
  ]
}

Should I just be adding this back to solve the problem? I guess I need to read up on this

8

Well

If you need a service worker for B then the answer obviously is yes

But your original issue reported by ypur user is probably caused by a undesirable update strategy as per configuration in A

So unless ypu change that your future will look the same for C etc. And the update strategy is not shown here. Plse read the full angular docs on service worker update strategies and config (app.module.ts) etc. Als swUpdate service is relevant here

Service workers are cool things to add but bite you if you lack the knowledge

1 Like
9

Thanks @Tommertom we certainly don’t need the service worker - so presumably either we can disable it on the server somehow(?) or deploy a new version with some sort of strategy config change? (If I’m understanding correctly). Thanks for your time and help. To be honest I don’t really understand why the service worker is still operational if the new version of the deployed app does not have that file anywhere?

10
1 Like
11

Please check you deployment server configuration.
Disable index.html caching on the server side.

12

I have a single page web-application (HTML and JS only) that clients visit in their web browser.

If I upload a new version of the web application, the client will still load the old version when visiting the website.website developer dubai To really load the new version, the client has to clear the cache (or disable cache). I am using Firefox so I have to open the inspector, and select the “Disable cache” in the network tab (see picture below).

This is annoying. From college I have a vague memory that HTTP has a header that tells the client that “there is a new version of the website”. But is this something I have to enable in the web server application (Apache2)?

13

Had the same kinda issue, this thread proved out to be very helpful indeed. Cheers..…

1 Like
14

I’ve still not fixed this issue @Tommertom - I followed the instructions in the link you kindly posted above and in a few other discussions I had seen on this topic i.e I

Removed the ngsw-worker.js file from the project
Removed the ngsw.json file (mentioned in your link under Fail-Safe) from the project
Added a safety-worker.js file (mentioned in your link under Safety-Worker)
Set serviceWorker:false in my angular.json file
in app.module I changed the reference in the ServiceWorkerModule.register section from ngsw-worker.js to safety-worker.js

I thought all of the above would result in the app now being served without any service-worker interference at all. The new web files were deployed on our server yesterday. I just hit the site and once again the old version of the site is loaded. In Chrome DevTools if I click on Application-Service Workers I can see ngsw-worker.js and on the network tab a lot of files with an initiator of ngsw-worker.js

I can’t seem to get rid of it!

I’m obviously not fully understanding what I need to do to disable the service worker. I thought my steps above would work but it appears they haven’t. I just want the site to be served service worker free so I can be sure all users get the latest versions. Can you see what I have done wrong or is there a step I have missed?

15

How does the site load in incognito mode? That is basically what new users will see

Can u share a link to the page?

I have never worked wirh safety worker. But that is because of lack of experience on my end with really awefull service worker situations

1 Like
16

Hi. I just tried private browsing mode on my iPad - I’m not at my desktop machine right now - and the new version of the site loaded ok rather than the one old one. But it’s existing users (who have previously loaded the site with the service worker) that I need to sort out. I was expecting the steps I have taken to have disabled this service worker and causes ALL users to ALWAYS load the new web pages.

I can’t share the actual site I’m afraid as I would need to give some authentication credentials. Thanks for checking in on this!

17

Hi

Strictly spoken I don’t need access - so first load is fine. But I guess it won’t help much as via incognito you have a clean and controlled version. That is what I would see.

Your problem is indeed that the old service workers keep hanging in old versions of the app.

I have no experience with the safety workers etc.

In that case I would experiment with a bit more hacky ways to get rid of it. For instance, placing some javascript code in index.html that checks for service workers and then kills them. Maybe even choosing to register the new ones in a separate name - and see if I can identify the old service worker to kill them. More brute force is to kill all service workers in javascript/index.html until all users have swept through. And then start over again with a better one.

image

You do need to implement an update routine in the app - otherwise you can start over again.

Either way, it requires a bit of deeper understanding of the situation of the old service worker.

And best is to experiment with this in a separate project until it works

Other ways could be to code a hard document.reload in the new portion that gets loaded before the old code is shown (if at all). Again - important to experiment before putting in production.

1 Like
18

Thanks @Tommertom I think I finally managed to rid the app of this service worker - the only way I managed to get this to work was to add this code at the top of my app.component.ts file:

if ('serviceWorker' in navigator) {
      navigator.serviceWorker.getRegistrations().then(function (registrations) {
        //returns installed service workers
        if (registrations.length) {
          for(let registration of registrations) {
            registration.unregister();
         }
        }
 });
}

Before I added this, first time I went to the site the old version of the site would load. Subsequent hits would load the new site for X hours then the old one would load again.

Now, with the above code added it seems as if once that new site has loaded the service worker is unregistered. This code is not mentioned in any angular docs as far as I can see - only in various discussion threads about how to disable service workers. For now I’m hoping the above continues to work. Thanks again.

1 Like
19

Thx for sharing - I guess your post has made the solution accessible for many years to come!

1 Like