Develop Reference

Does sw-precache activation of new service worker guarantees cache busting?

I am using sw-precache along with sw-toolbox to allow offline browsing of cached pages of an Angular app.
The app is served through a node express server.
One problem we ran into is that the index.html sometimes doesn't seem to be updated in the cache although other assets has been updated on activation of new service worker.
This leaves users with an outdated index.html that is trying to load no longer existing versioned asset in this case /scripts/a387fbeb.modules.js.
I am not entirely sure what's happening, because it seems that on different browsers where the index.html has been correctly updated have the same hash.
On one browser outdated (problematic) Index.html
(cached with 2cdd5371d1201f857054a716570c1564 hash) includes:
<script src="scripts/a387fbeb.modules.js"></script>
in its content. (this file no longer exists in the cache or on remote).
On another browser updated (good) index.html
(cached with the same 2cdd5371d1201f857054a716570c1564) includes:
<script src="scripts/cec2b711.modules.js"></script>
These two have the same cache, although the content that is returned to the browsers are different!
What should I make of this? Does this mean that sw-precache doesn't guarantee atomic cache busting when new SW activates? How can one protect from this?
If these help, this is the generated service-worker.js file from sw-precache.
Note: I realize I can use remoteFirst strategy (at least for index.html) to avoid this. But I'd still like to understand and figure out a way to use cacheFirst strategy to get the most out of performance.
Note 2: I saw in other related questions that one can change the name of the cache to force bust all the old cache. But this seems to beat the idea of sw-precache only busting updated content? Is this the way to go?
Note 3: Note that even if I hard reload the browser where the website is broken. The site would work because it would skip service worker cache but the cache would still be wrong - the service worker doesn't seem to activate - my guess because this specific SW has been activated already but failed at busting the cache correctly. Subsequent non-hard-refresh visits would still see the broken index.html.

(The answers here are specific to the sw-precache library. The details don't apply to service workers in general, but the concepts about cache maintenance may still apply to a wider audience.)
If the content of index.html is dynamically generated by a server and depends on other resources that are either inlined or referenced via <script> or <link> tags, then you need to specify those dependencies via the dynamicUrlToDependencies option. Here's an example from the app-shell-demo that ships as part of the library:
dynamicUrlToDependencies: {
'/shell': [
...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`),
...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`),
`${SRC_DIR}/views/index.handlebars`
]
}
(/shell is used there instead of /index.html, since that's the URL used for accessing the cached App Shell.)
This configuration tells sw-precache that any time any of the local files that match those patterns change, the cache entry for the dynamic page should be updated.
If your index.html isn't being generated dynamically by the server, but instead is updated during build time using something like this approach, then it's important to make sure that the step in your build process that runs sw-precache happens after all the other modifications and replacements have taken place. This means using something like run-sequence to ensure that the service worker generation isn't run in parallel with other tasks.
If the above information doesn't help you, feel free to file a bug with more details, including your site's URL.

cordova window.location.href behaviour error

In my assets/www/index.html, I am trying to open html in the
/data/data/files/xyz/index.html with this javascript command:
window.location.href = cordova.file.dataDirectory + "xyz/index.html";
In the ../xyz/index.html it also included the cordova.js which exists on the same xyz directory:
<script type="text/javascript" src="cordova.js"></script>
The index.html can be loaded, but in the catlog show error like below
W/CordovaWebViewImpl﹕ Blocked (possibly sub-frame) navigation to
non-allowed URL: gap://ready
is there something wrong with my method? Is it wrong to use window.location.href to open another cordova application in the data folder ?
EDIT : I already found the root cause, that is my cordova.js in the /data/data/files/xyz/cordova.js is having different version with the one in asset folder. after i copied the same cordova js version, it can be loaded without error warning. Thanks.

You don't need to use "cordova.file.datadirectory". That's only if you use the file plugin for accessing data files, such as saving high-scores in a game or level data. You do not use the plugin for loading/unloading pages into the current webview.
You would want all of your HTML files to be in the same folder branch as your "index.html". Assume a directory structure like this:
/ index.html <!---- this is your current index.html
/ page2.html
/ js / index.js
/ xyz /index.html
All you would have to do is window.location='xyz/index.html'. However, I strongly encourage you to not replace entire pages if you're developing for iOS. It's almost a guarenteed way to get your app rejected. Try loading your pages in via AJAX using a framework like "Framework7".
NOTE: You can only view files within the webview, that are in the same folder or are children of, as your initial index.html.
EDIT: You want to load another Cordova webview application. I'd suggest still making it a child of the initial "index.html" folder. However, you might be able to write a plugin or customize the platform itself to access the other files. However, that's out of the scope of this question!

Drupal CSS and JS

I'm working on a project where I made a copy of a live site on to my localhost to work on. I've made updates to a sub theme css/js, added the new CSS file to the sub theme .info file, and modified the preprocess_page and added the JS with the drupal_add_js method.
All this seems to work very well on my localhost, but pushing live, the site still picks up the old CSS/JS files.
I cleared all caches I could find:
Site Configuration/Advanced CSS/JS Aggregation/Smart cache flush
Site Configuration/Advanced CSS/JS Aggregation/Cache Rebuild
Site Configuration/Performance/Clear cached data
but I'm still getting the same result. The old CSS/JS files persist. Where am I going wrong?

Yes, Drupal sometimes jamming, despite cleaning the caches...
I was then helped by deleting files from these folders:
./sites/default/files/css
./sites/default/files/js
Note: If you want this, instead of deleting it, you can move it to another folder.

How do I set my relative path in a user controll that is shared

I have the following solution structure.
cabinet (folder)
cabinet.aspx
images (folder)
script (folder)
folder1
menu.js
userControl (folder)
menu.ascx
default.aspx
Inside of userControl I have menu.ascx (UserControl).
Inside of menu.ascx I am referencing several .js files. For example:
<script src="./script/folder1/menu.js"></script>
When I view the default.aspx that calls menu.ascx it works fine.
However, when I'm in the cabinet folder looking at cabinet.aspx (cabinet\cabinet.aspx) that also calls menu.ascx
<%# Register Src="../userControl/menu.ascx" TagName="menu" TagPrefix="uc2" %>
The menu code is in the source but the menu.js file is a 404
http://localhost/cabinet/script/menu-files/menu.js
It looks like it needs to go directory further out. I would of expected it to go to:
http://localhost/script/menu/menu.js
What do I need to do to accomplish this?

One of two approaches:
Anchor the script reference to the site root with an absolute reference via "/script/folder1/menu.js" (note how it starts with a forward slash). For example, <script src="/script/folder1/menu.js"></script>. This says to look at the root of the site and carry on from there.
Have the script tag runat="server" and root it to the application root via "~/script/folder1/menu.js" (note the "~/" start). For example <script runat="server" src="~/script/folder1/menu.js"></script>. This determines the site root server-side and generates the correct path accordingly.
In all cases except for when your development environment doesn't allow it (I'm showing my age there going back to WinXP for development) or you are configuring an app that will live in a virtual application sub-directory in your site, go with the first option.

I figured out that the issue was the Visual Studio Web Instance that was being fired off and the fact that there were headers that needed to be set on IIS to allow the code to work.
So essentially I installed IIS 7.5 and created a site and now I just attach to the process to do my debugging for this.
Once I got IIS setup correctly the paths that were in code worked.

Restart Apache Tomcat to serve changed Javascript files?

I was under the impression that if I deployed my application (using Ant) then JS files, along with HTML, CSS and images, would be automatically served by Tomcat.
However, after editing Javascript files I have to restart Tomcat in order for the changes to be updated.
My JS files are in a 'js' directory off of root (not in WEB-INF).
I am using FF3.6.
Any help?

I 've never worked with Tomcat but I find it hard to imagine it wouldn't serve changed JS files straight awayafter deployment. My guess is this is a caching issue on the browser's side. Can you try to force a refresh by opening the actual CSS file and pressing F5?
The usual approach to making sure a JS file gets updated is embedding it with a GET parameter that marks the version/revision:
<script type="text/javascript" src="/js/script.js?version=51"></script>
when you update the script's revision, and change the GET parameter, the browser should forget the cached version and re-load the file.

According to http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
cachingAllowed -
If the value of this flag is true, the cache for static resources will be used. If not specified, the default value of the flag is true.

I found out that Tomcat reload files from the /temp directory which was set by setting antiresourcelocking to true in the context xml's. Thanks guys.