This might be associated with this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=824762

@Reporter: Please provide sample URL/test file to test this issue from TE end. This would help in further triaging of the issue.

Thanks!

Setup a site with three documents, index.html, manifest.txt, and something that returns a different image on each request.

The image should be embedded in the index.html, the url should be included within the manifest.txt under the cached section.

Once the downloaded event fires from the applicationCache, the image should not change unless the manifest.txt changes.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Setting up a site with three documents, index.html, manifest.txt, and something that returns a different image on each request is out of scope for ET team (...to create/setup). Hence requesting you to provide a sample test URL/File which helps us to triage the issue in a better way. Any further inputs from your end may be helpful.

Thanks!

Ok, I think I have this figured out. Prior to Chrome 66, if the comments in a manifest changed, the whole thing was flagged dirty.

Now on 66, the comments are ignored. 

When serving my manifest file, I have the startup timestamp of the application added to a comment.

As a work-around, I'm putting a junk url in the NETWORK: section.
like chrome.html?98723490875 where 98723490875 is the server startup timestamp.

-Josh

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

"if the comments in a manifest changed, the whole thing was flagged dirty. Now on 66, the comments are ignored."

There are no changes that would account for such behavior. The comparison is still a bytewise compare between the old and new manifest content. https://cs.chromium.org/chromium/src/content/browser/appcache/appcache_update_job.cc?sq=package:chromium&g=0&l=923

... so I wouldn't be too confident about the workaround. It's likely something else going on...

@Reporter:As per comment #4 and comment #8 without proper test file we couldn't test this issue. could you please provide sample URL/test file to test this issue from TE end. This would help in further triaging of the issue.

Thanks!

Same issue here on chrome 67. The browser fires the Application Cache NoUpdate event although the manifest has changes the comment section.

I have added "Cache-Control: no-update,no-store" to the HTTP response for the manifest file, but that didn't solve the issue.

Does it have something to do with the "stuck with a particular version forever" issue? [1]

[1] https://developers.google.com/web/updates/2018/06/fresher-sw

When the cache will not be updated forever then this bug should have the priority of a showstopper.

The workaround with the junk URL in the NETWORK section didn't work. What else could we try to work around this bug?

"Setting up a site with three documents, index.html, manifest.txt, and something that returns a different image on each request is out of scope for ET team"

=> Where is the ET team and why don't they ask Google for help? The biggest player in internet technology should be able to setup a simple webserver.

Update: I have tested a lot and now I am quite sure that there is no issue with the appcache in chrome 66 and 77. My problem was just a mistake in my own code which didn't handle the appcache events correctly. I have tested on both version 66 and 67 and everything works as expected in all cases: On initial load, on reload and on update.

Thanks for following up!

Whooops, re-opening - that wasn't the OP.

No feedback from original poster (requested sample files)

Closing pending further data.