820563 - Have a mechanism to invalidate AppCache from content

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect)

Description

[David Burns :automatedtester]

Application Cache would be better if there was a mechanism to invalidate the cache from content in the same way that cookies can be invalidated from content. 

This will allow users to control when their appcaches in the same way that they do their cookies if need be.

Comment 1

[Honza Bambas (:mayhemer)]

(In reply to David Burns :automatedtester from comment #0)
> Application Cache would be better if there was a mechanism to invalidate the
> cache from content in the same way that cookies can be invalidated from
> content. 
> 
> This will allow users to control when their appcaches in the same way that
> they do their cookies if need be.

You mean user (the one at the keyboard) or web admins that control the web content?

I'm not sure how this should work.  The API would be exposed on window.applicationCache object.  It can be connected with an actual app cache only though corresponding manifest attribute in the html tag.  When content calls say applicationCache.clear() then what is going to happen?  Since, if we just throw the cache away, it will be downloaded again on next page visit (or reload) thanks the manifest attribute referring a valid manifest.  Deleting the manifest from the server actually deletes the app cache from the disk, and it is already implemented.

David, feel free to state better how this should work.  It may not be clear from the description what you actually want.

Comment 2

[David Burns :automatedtester]

:Honza

This is for web admins/developers/testers really. 

I know that the next page is visited is going to download it but a user might want that to happen. The use cases I have in mind, and if they can be done already then awesome.

1. User visit's site A. Site A uses CDNs and there has been a bad push to the node for the User's closest node. User clicks something that fires javascript that was downloaded and cached, as per appcache rules but that errors. Site A has implemented window.onError to capture error messages and post back to site when there are errors (DropBox does this) and then does window applicationCache.clear() (if it were there) so if the user does a reload, visits next page, or site sends a confirmation its doing a reload, it tries to download the files again and hopefully gets a fixed version.

2. A tester is testing a website that uses appcache as part of offline solution for the site(which is what everyone is advocating at the moment) and wants to do negative testing of there being no cache. The website polls to see if the server is there and uses cache for when a user clicks something that is normally cached. E.g. Gmail shows some cached messages if they are there, if not it says it can't show the message.

The tester can do this manually but there is no mechanisms for this with automated testing.

3. Developer has created a site that a user is designed to be on all day but is a single page site(which are all the rage). Developer does a push to the web servers and part of the long polling that the site might do gets a message to update the cache and then clear()s the cache and does a reload (or something along those lines).


The main one for me really is 2. since I help webqa or web testers with Selenium and work on Selenium and at the moment there is no way to clear an appCache during an automated test without having access to the chrome. Developers can easily expire cookies from JavaScript and I hope there could be a mechanism to do the same with appCache and it doesnt necessarily need to be clear() it could be setExpires(aDate).

I hope I have explained my thoughts well enough. Feel free to ping me on IRC or we can chat over skype/vidyo if not.

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to David Burns :automatedtester from comment #2)
> :Honza
> 
> This is for web admins/developers/testers really. 

First, sorry for late anser.

> 
> I know that the next page is visited is going to download it but a user
> might want that to happen. The use cases I have in mind, and if they can be
> done already then awesome.
> 
> 1. User visit's site A. Site A uses CDNs and there has been a bad push to
> the node for the User's closest node. User clicks something that fires
> javascript that was downloaded and cached, as per appcache rules but that
> errors. Site A has implemented window.onError to capture error messages and
> post back to site when there are errors (DropBox does this) and then does
> window applicationCache.clear() (if it were there) so if the user does a
> reload, visits next page, or site sends a confirmation its doing a reload,
> it tries to download the files again and hopefully gets a fixed version.

I don't see a point in this.  Reload doesn't guarantee the script is gonna work.  If there is a bug, it should be fixed and new manifest deployed by web admins.  AppCache is updated atomically, however, it doesn't guarantee the desired resource versions are downloaded to the browser.

New appcache spec (in progress) should address this a bit better.

> 
> 2. A tester is testing a website that uses appcache as part of offline
> solution for the site(which is what everyone is advocating at the moment)
> and wants to do negative testing of there being no cache. The website polls
> to see if the server is there and uses cache for when a user clicks
> something that is normally cached. E.g. Gmail shows some cached messages if
> they are there, if not it says it can't show the message.
> 
> The tester can do this manually but there is no mechanisms for this with
> automated testing.

This one is interesting.  However, if the server content is fully under your control, you can ping the server to update the manifest "version" (e.g. change a comment in it) before reload of your page.

> 
> 3. Developer has created a site that a user is designed to be on all day but
> is a single page site(which are all the rage). Developer does a push to the
> web servers and part of the long polling that the site might do gets a
> message to update the cache and then clear()s the cache and does a reload
> (or something along those lines).

Not sure I follow.  But it seems that applicationCache.update() and .swap() is the API you may use here.

> 
> 
> The main one for me really is 2. since I help webqa or web testers with
> Selenium and work on Selenium and at the moment there is no way to clear an
> appCache during an automated test without having access to the chrome.
> Developers can easily expire cookies from JavaScript and I hope there could
> be a mechanism to do the same with appCache and it doesnt necessarily need
> to be clear() it could be setExpires(aDate).