In HTML caching, my understanding is that when the manifest file is updated on the server, the browser downloads the latest files and swaps the cache.
Is there a way to stop the browser doing this until the user gives the go-ahead?
For example, displaying a notification to the user saying something like "there is a new version available. Do you want to download it? Y/N". If the user says "No", then the browser should keep the old files around.
Handle the updateready event and then conditionally call swapCache().
Related
In one of the online documents that talks about appcache for HTML5, it indicates that the cached files get updated once an offline user reconnects. I checked the original HTML5 appcache definition by W3, and I am not able to find anything that supports this statement.
Does anyone know if this is to be true?
Thanks in advance
MDN says the following, although if you scroll up on that page it says it's being deprecated.
If an application cache exists, the browser loads the document and its associated resources directly from the cache, without accessing the network. This speeds up the document load time.
The browser then checks to see if the cache manifest has been updated on the server.
If the cache manifest has been updated, the browser downloads a new version of the manifest and the resources listed in the manifest. This is done in the background and does not affect performance significantly.
And logic tells me that it would also depend on the app you're using, server you're trying to connect to and any special settings it might have, how long your browser keeps it's history, what it keeps, and if you saved the page to view offline - whether or not you have all the code/images saved in the right location(s).
Example:
Imagine you saved a page to view offline, and that page has a JS event handler that ran a while loop that did an ajax request every n seconds to do something, like make a number on a page change as long as you were online... As long as the loop is running, you suddenly connect to the internet, and it makes the request to the proper url with the right arguments, then it should go through, even though the url in your browser might say something like file:///C:/Users/you/Desktop/....
I've done this before, even though my url was like the one above. One time I was using braintree's drop-in javascript to a website, and using it's api on my backend. Trying to load the page when offline = Nothing. Online = Updated the spot on the page just fine when I had the required arguments, and it was pointing to the right url. If I got offline again, I could refresh the page, see the same images loaded in the <div>, but I couldn't send any data with it.
I am trying to make a webapp that will load a page from a remote server, but allow the user to play audio from files that are on their local drive (not downloaded from the remote server). I am able to get this to work, but I also need it to save what the user has done for subsequent visits. For example: the user loads a page, clicks a "choose file" button, selects an mp3, and plays it. The user then closes the browser, opens it again, returns to the page, and is able to play the same audio without having to select it again.
I understand that the audio playback is separate from the saving of the user's selection, but in this case one seems to dictate the other.
I am able to get the select-and-play functionality to work with this:
<html><body>
<script type='text/javascript'>
function handleFiles(files){
var file = window.URL.createObjectURL(files[0]);
document.getElementById('audioPlayer').src = file;
}
</script>
<audio id='audioPlayer' controls ></audio>
<input type='file' id='selectedFile'
onchange='handleFiles(this.files)' />
</body></html>
...but I do not know how to store the selected file data in a way that I can automatically load it on the next visit. What can I use to store that file location (or even the whole file itself if it comes to it) so that I can still play the audio without the user selecting the file again?
I kind of suspect that saving the local file url somehow may not be possible for security reasons, since auto-playing a file from the local file system without user interaction could be bad news.
File handles from File open dialog are not recycleable across different page load sessions.
The best you can do this that you copy audio data to a HTML5 localStorage and play it from there. Or upload the data to your server and play it from there.
http://docs.webplatform.org/wiki/apis/web-storage/Storage/localStorage
localStorage is limited to few megabytes depending on the browser.
At this time, Mikko's answer is the correct answer for my question, but I thought I'd share a possible alternative for anyone else who comes across this thread:
The FileSystem API looks like it would perfectly suit my needs in this case, but at the time of this writing, it is only supported in Chrome. If audio playback is a minor add-on feature to your webapp though, this might be an option to give Chrome users a better experience and other users would just be unaware that they're missing out.
In this HTML5 Rocks article, the author shows how to use it, including how to copy user-selected files into a local disk sandbox and how to get a url (needed in my case to audio playback) to those files.
I have a cache manifest with a comment in it
# Version 3.2
in order to update all the App I simply change the Version number. It works, but:
When I update the manifest, everything is updated correctly (new cache is filled) but the actual files are taken ONE more time from the (old) cache. when I reload twice everything is updated. Is this behaviour correct? Using chrome 21.
Thanks
Yes, this is the current "correct" behaviour. This is what happens:
When you just made changes to the manifest file, and you refresh the browser, this is what happens (assuming you're online)
the browser first loads back all the files in the cache
then the browser check online for your manifest file
it detects that the manifest file has changed, it will then proceed to download the new files
however, keep in mind, at this time, you will still be looking at your 'old files' because the browser has loaded the old files before going online to download the 'new files'
if at this point, if you hit refresh again (2nd time), you should get the 'new files'
This is currently the standard behaviour. Some people put some event handlers to prompt the user to do another refresh (after the 1st refresh)
Personally, I think the browser should be responsible to alert the user to make another refresh after finish downloading the new files, but right now, most people put in event handlers from the "window.applicationCache" to fire events to help manage this.
To look at an example of using window.applicationCache, go here : http://www.html5rocks.com/en/tutorials/appcache/beginner/
it's under the "Updating the Cache" section.
It is possible to instantly swap the cache as described here:
function updateSite(event) {
window.applicationCache.swapCache();
}
window.applicationCache.addEventListener('updateready', updateSite, false);
I'm using HTML5 appcache and mostly it's working well. However, sometimes, users' browsers (Chrome or Safari) will hold onto the cached manifest file even though I'm positive that the server has a brand new manifest file with a unique version number inside of a comment (like with "# app version 1.0.0.8" or whatever).
In IIS (version 6), the content expiration was set to 1 day, so could that be the problem? I can't seem to reproduce this issue which makes debugging difficult. As a precaution, in IIS I've changed the content expiration to "expire immediately" for the directory that stores the manifest file. Could that explain why some browsers were hanging onto manifest files even when a new version was available?
I also noticed that when a browser was behaving this way, even if I deleted the manifest file on the server, the user's browser would use its own cached copy of the manifest file which isn't supposed to happen if the file is no longer available in my understanding.
Thanks,
Andy
Taken from my answer here : https://stackoverflow.com/a/13282735/727575
Yes, this is the current "correct" behaviour. It has nothing to do with IIS content expiration. This is what happens:
When you just made changes to the manifest file, and you refresh the browser, this is what happens (assuming you're online)
the browser first loads back all the files in the cache
then the browser check online for your manifest file
it detects that the manifest file has changed, it will then proceed to download the new files
however, keep in mind, at this time, you will still be looking at your 'old files' because the browser has loaded the old files before going online to download the 'new files'
if at this point, if you hit refresh again (2nd time), you should get the 'new files'
This is currently the standard behaviour. Some people put some event handlers to prompt the user to do another refresh (after the 1st refresh)
So basically, you need to refresh twice or throw one of the event from 'window.applicationCache' to handle it
To look at an example of using window.applicationCache, go here : http://www.html5rocks.com/en/tutorials/appcache/beginner/
it's under the "Updating the Cache" section.
HTML 5 offline logic is encapsulated in window.applicationCache object. However it looks like it's not possible to programmatically clear cache data, for example, when user logs off from the system. Is there any other way to clear HTML 5 application cache, except for generating empty manifest file?
Have observed this on Chrome not sure if that's the standard way, if server responds with 404 on manifest file request, cache gets cleared from browser after raising obsolete event.
Setting aside the specifics of the HTML5 appcache, clearing a browser's cache programmatically has never been possible (beyond certain ActiveX controls for that browser) so I suspect you may come up empty on this one. Perhaps you should focus on the cache control meta tag and test further with your empty manifest idea?
I think the best way to do this is to change the link to the manifest file. In this case I would append the user's session ID to the manifest file. Every user should have session regardless of logged in status and the session ID should probably changed when logging in/out (maybe).
I also found this answer: Removing HTML5 Appcache Manifest, Permanently