Bug 41637 – Web Inspector: Give Semantics to "Refresh" and "Delete" Buttons in ApplicationCache DataGrid

• Status: RESOLVED
• Resolution: LATER
• Component: Web Inspector (Deprecated)

[Joseph Pecoraro]

Discussion on what these should do can happen here.

[Michael Nordman]

We have a "Delete" function in chrome which could be wired to this button. The semantics of that function are to immediately delete from persistent storage all of the resources associated with the ApplicationCacheGroup. After doing this, sub resource loads in all pages associated with any cache from that group will fail.

"Refresh" could mean, call .update() and when the update completes call .swapCache() if the cache status is UPDATE_READY. And then repopulate the display with the new contents of the updated cache.

[Timothy Hatcher]

Does WebKit have a "'Delete' function", why is that specific to Chrome?

[Michael Nordman]

(In reply to comment #2)
> Does WebKit have a "'Delete' function", why is that specific to Chrome?

It's not specific to Chrome, I'm just sharing what semantics we put in place for this function in Chrome.

[Timothy Hatcher]

And Chrome does not share WebKit's semantics?

[Michael Nordman]

(In reply to comment #4)
> And Chrome does not share WebKit's semantics?

Not always. Incognito vs PrivateBrowsing for example. Also, as in this case, when chrome has a function that WebKit has not yet implemented. We needed this administrative capability to delete an appcache when we released the feature in chrome and those are the semantics we devised (fwiw).

[Joseph Pecoraro]

(In reply to comment #1)
> We have a "Delete" function in chrome which could be wired to this button. The semantics of
> that function are to immediately delete from persistent storage all of the resources associated
> with the ApplicationCacheGroup. After doing this, sub resource loads in all pages associated
> with any cache from that group will fail.

I don't see the usefulness of this type of delete. It sounds like the only way to make the
web application useful again would be to change the manifest.

I was thinking "Delete" would actually eliminate the application cache you're viewing. The
use case goal being you can use the delete button, and then refresh the page to re-download
the resources _even if the manifest didn't change_!! Is it enough to just "obsolete" the current
application cache? Considerations would include disabling the delete button when its
not appropriate.


> "Refresh" could mean, call .update() and when the update completes call .swapCache()
> if the cache status is UPDATE_READY. And then repopulate the display with the new
> contents of the updated cache.

I think this is a great idea. The difference between this an the "Delete" semantics I describe
above would be that here nothing would be re-downloaded if the manifest has not changed.

[Michael Nordman]

(In reply to comment #6)
> (In reply to comment #1)
> > We have a "Delete" function in chrome which could be wired to this button. The semantics of
> > that function are to immediately delete from persistent storage all of the resources associated
> > with the ApplicationCacheGroup. After doing this, sub resource loads in all pages associated
> > with any cache from that group will fail.
> 
> I don't see the usefulness of this type of delete. It sounds like the only way to make the
> web application useful again would be to change the manifest.

After the delete i described, reloading the page *would* create a new cache group and download all over again (yada yada). Any other pages however still associated with the old cache would still be non-functional wrt sub-resource loading.

> I was thinking "Delete" would actually eliminate the application cache you're viewing. The
> use case goal being you can use the delete button, and then refresh the page to re-download
> the resources _even if the manifest didn't change_!! Is it enough to just "obsolete" the current
> application cache? Considerations would include disabling the delete button when its
> not appropriate.

I think you just tacked on another automated step, the delete function i described earlier + an auto reload the page step. For my tastes, the auto reload part would be doing more than I want. I can easily enough reload the page on my own.

The "obsolete" semantics are an option. I didn't use those semantics in chrome because stuff has to linger in memory and on disk until pages using caches in that group go away of their own accord. I wanted to make it go away NOW.

> > "Refresh" could mean, call .update() and when the update completes call .swapCache()
> > if the cache status is UPDATE_READY. And then repopulate the display with the new
> > contents of the updated cache.
> 
> I think this is a great idea. The difference between this an the "Delete" semantics I describe
> above would be that here nothing would be re-downloaded if the manifest has not changed.

Another big difference is that there is no auto-reload of the page being inspected.

[Joseph Pecoraro]

> I think you just tacked on another automated step, the delete function i described earlier + an
> auto reload the page step. For my tastes, the auto reload part would be doing more than I want.
> I can easily enough reload the page on my own.

I wasn't clear enough. I didn't mean to make it sound like an auto-reload. I meant the
user could than reload the page to re-download.

[Michael Nordman]

(In reply to comment #8)
> > I think you just tacked on another automated step, the delete function i described earlier + an
> > auto reload the page step. For my tastes, the auto reload part would be doing more than I want.
> > I can easily enough reload the page on my own.
> 
> I wasn't clear enough. I didn't mean to make it sound like an auto-reload. I meant the
> user could than reload the page to re-download.

I think we're saying the same thing then.

It was me that was not clear enough. I said "delete all resources"... sorry, what i should have said is "delete all traces" including all database records. That's the behavior we have for the delete function. The applicationCache.status attribute in pages that are associated with this group does get set to OBSOLETE when we're in this state (for lack of a better state to put it in), but really its beyond OBSOLETE, stuff has actually been deleted.

[Joseph Pecoraro]

> It was me that was not clear enough. I said "delete all resources"... sorry, what i should have said
> is "delete all traces" including all database records. That's the behavior we have for the delete function. 
> [...] but really its beyond OBSOLETE, stuff has actually been deleted.

Okay, than I am good with it. I have a minor point, that we should stop downloading resources
if it is in the process of downloading resources. But I think that is a natural assumption.

This appears to be the behavior of WebKit's ApplicationCacheGroup::makeObsolete. It makes the
Group Obsolete, and removes Database entries without even checking for other documents
that may actively be using that ApplicationCache (HTML5 spec seems to make that point). Might
be a bug, or might actually work just fine.

What do you propose the interface for this be? How about:

  ApplicationCacheHost::deleteSomethingCacheGroup()

Where "Something" would be a more descriptive word like, "Associated", "Relevant", "Active",
or "Candidate". The spec doesn't give a technical name to this chosen relevant cache. I thought
an older version used the word candidate:
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#cache-host

[Michael Nordman]

(In reply to comment #10)
> What do you propose the interface for this be? How about:
> 
>   ApplicationCacheHost::deleteSomethingCacheGroup()
> 
> Where "Something" would be a more descriptive word like, "Associated", "Relevant", "Active",
> or "Candidate". The spec doesn't give a technical name to this chosen relevant cache. I thought
> an older version used the word candidate:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#cache-host

Yes, an instance method that takes no parameters is good. ApplicationCacheHost::deleteCacheGroup() w/o the something would be a reasonable name too. But if that's not descriptive enought either  or ApplicationCacheHost::deleteAssociatedCacheGroup() or deleteSelectedCacheGroup() would work too. The spec using the term "associated" in some places and then the term "selection algorithm" in other places to figure out what that "association" should be.

[Michael Nordman]

(In reply to comment #10)
> This appears to be the behavior of WebKit's ApplicationCacheGroup::makeObsolete. It makes the
> Group Obsolete, and removes Database entries without even checking for other documents
> that may actively be using that ApplicationCache (HTML5 spec seems to make that point). Might
> be a bug, or might actually work just fine.

Not a bug... WebKit's impl holds all resources in memory for caches that are in use, so documents that are associated will still be able to access those resources even after makeObsolete has done its work. 

Chrome's impl doesn't hold everything in memory so when a group is made obsolete we can't delete the resource data from disk. Equating this delete function to making a group obsolete is close but not quite right.

[Joseph Pecoraro]

> Not a bug... WebKit's impl holds all resources in memory for caches that are in use,
> so documents that are associated will still be able to access those resources even
> after makeObsolete has done its work.

Oh. Thanks for that explanation!


> Chrome's impl doesn't hold everything in memory so when a group is made obsolete
> we can't delete the resource data from disk. Equating this delete function to making
> a group obsolete is close but not quite right.

Okay. Well, in either case, when to delete something from disk sounds like an
implementation detail. I think from a user standpoint, the action they would want to
perform is "make this cache group obsolete" and how the implementation handles
things (deleting from disk or not) is not the user's concern. In Chromium's case, that
can be something you can choose to do.

For a potential user who develops using ApplicationCache, they aren't concerned
with the implementation details. They only know what the spec says, and to them
making something "obsolete" is itself a concrete action. I don't think they would
understand "make obsolete and delete from disk", because to them that is invisible.
This is just like your suggestion for "Refresh" to be action "update and swapUpdate",
that is a concrete action in high level application cache terms, not implementation
details.


> After doing this, sub resource loads in all pages associated with any cache from
> that group will fail.

To me this sounds like a very small drawback to the Chromium delete approach.
But, its certainly in no way harmful.

[Michael Nordman]

> For a potential user who develops using ApplicationCache, they aren't concerned
> with the implementation details. They only know what the spec says, and to them
> making something "obsolete" is itself a concrete action. I don't think they would
> understand "make obsolete and delete from disk", because to them that is invisible.
> This is just like your suggestion for "Refresh" to be action "update and swapUpdate",
> that is a concrete action in high level application cache terms, not implementation
> details.

That sounds reasonable.

> To me this sounds like a very small drawback to the Chromium delete approach.
> But, its certainly in no way harmful.

Or a small feature ;)

That delete function i described is wired to different user interfaces.

Not sure which semantics are better really, both would work. With delete now semantics, contexts tied to instances will clearly stop functioning. There will be less risk of confusing context tied to a deleted cache with context tied to renewed caches. With make obsolete semantics, the manifest url will be the same for each, but if you look very closely... one will say OBSOLETE for the appacche status display and the other will say IDLE... but may be too subtle of an outcome after explicitly pressing the delete button.

[Alexey Proskuryakov]

These buttons have been hidden in bug 60799 to avoid confusing developers. If we can't find and implement a good meaning for them, the code needs to be actually removed.

[Vsevolod Vlasov]

I believe there are actually three things that were discussed in this bug:

1) Refresh button (meaning refresh inspector data from backend) -- I think this one should be removed, since we can update everything from backend automatically. I created https://bugs.webkit.org/show_bug.cgi?id=72123 for that.

2) update/swapCache - I created https://bugs.webkit.org/show_bug.cgi?id=72153 for that.

3) Delete button - could be tracked by this bug since there was a long discussion about that here.