| Summary: | ApplicationCache - doesn't pick the "most appropriate" cache when there are multiple candidates | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Nordman <michaeln> | ||||||
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED WONTFIX | ||||||||
| Severity: | Normal | CC: | annevk, ap, commit-queue, michaeln, webkit.review.bot | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
Michael Nordman
2011-03-01 14:06:05 PST
Specifically, HTML5 says: ----------------------------------- Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following: which application cache was most recently updated, which application cache was being used to display the resource from which the user decided to look at the new resource, and which application cache the user prefers. ----------------------------------- Cross platform WebKit code makes no attempt to implement that yet, indeed. > Cross platform WebKit code makes no attempt to implement that yet, indeed.
Neither does chrome, but this seems like a pretty big rough edge that i'm interested in smoothing out. Doing so may involve changes to some of the code that we do share...
"which application cache was being used to display the resource from which the user decided to look at the new resource"
... arranging for that input in particular when choosing which cached main resource to load.
Created attachment 85753 [details]
frameParam
Some groundwork for fixing this in chromium. An additional webFrame parameter to a webkit api so chromium's impl has enough info to figure out the "most appropiate".
Attachment 85753 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebKit/chromium/ChangeLog', u'Sourc..." exit_code: 1
Source/WebKit/chromium/public/WebApplicationCacheHost.h:80: One space before end of line comments [whitespace/comments] [5]
Total errors found: 1 in 3 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 85762 [details]
frameParam
fix style'ism
Comment on attachment 85762 [details]
frameParam
OK. I would suggest fixing cross-platform code behavior first if possible though. As this is an observable behavior, it's something we should maintain parity at, and working on code that has more parties interested in would guarantee fewer surprises than backporting from Chromium branch.
The commit-queue encountered the following flaky tests while processing attachment 85762 [details]: transitions/interrupted-accelerated-transition.html bug 56242 (authors: simon.fraser@apple.com and tonyg@chromium.org) The commit-queue is continuing to process your patch. Comment on attachment 85762 [details] frameParam Clearing flags on attachment: 85762 Committed r81183: <http://trac.webkit.org/changeset/81183> All reviewed patches have been landed. Closing bug. reopening, the initial patch was just some groundwork The commit-queue encountered the following flaky tests while processing attachment 85762 [details]: transitions/interrupted-accelerated-transition.html bug 56242 (authors: simon.fraser@apple.com and tonyg@chromium.org) The commit-queue is continuing to process your patch. My plan for this in chrome is to modify the storage.FindResponseForMainRequest method to accept an additional input about which manifest_url the caller would like a bias towards, and to provide that input based on the manifest used by the opener|parent. Ties would go to the resource from the preferred manifest_url. I've got a start at this here... http://codereview.chromium.org/6727006/ A further refinement could be to have a bias towards the manifest used by the document currently residing in the frame into which a new document is being loaded, but for now i'm just starting with what the opener|parent has to say. I have not looked at webcore's impl in any detail, but breaking ties in the same way should be possible there too. I've landed changes in the chromium along these lines, here's the CL description. Select a more appropiate appcache based on the opener or the parent or the target frame of the new document. The change determines a 'preferred manifest url' in these cases: * <iframe> loading, we prefer the parent frame's manifest url * window.open() loading, we prefer the opener frame's manifest url * href clicking to navigate a frame in place, we prefer the manifest url of the document in the frame when the navigation starts More details can be found here. http://code.google.com/p/chromium/issues/detail?id=68479 This feature is in the process of being removed. |