[Webkit-unassigned] [Bug 55505] New: ApplicationCache - doesn't pick the "most appropriate" cache when there are multiple candidates

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 1 14:06:05 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=55505

           Summary: ApplicationCache - doesn't pick the "most appropriate"
                    cache when there are multiple candidates
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: michaeln at google.com
                CC: michaeln at google.com


Please see http://code.google.com/p/chromium/issues/detail?id=68479 for some history.

-- some comments from the chromium bug ---

URLs?
http://dictionarymid.sourceforge.net/htmlApp/playground/EngLat_IDP1/
http://dictionarymid.sourceforge.net/htmlApp/playground/EngLat_IDP2/

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 3.x: FAIL 
  Firefox 4  : OK
       IE 7/8: N/A [does not support Application Cache]

What steps will reproduce the problem?
1. Open http://dictionarymid.sourceforge.net/htmlApp/playground/EngLat_IDP1/
2. Wait for application cache to be loaded (total of 127 files; press "cache info" and wait for status 'IDLE')
3. Open http://dictionarymid.sourceforge.net/htmlApp/playground/EngLat_IDP2/

What is the expected result?
The URL from step 3. is correctly loaded, no error occurs.

What happens instead?
An error window pops up: "XMLHttpRequestSend Exception 101"


Both manifests contain the same URLs from the ../htmlApp directory

#
# HTML files for mini_hmi
# 
.
../htmlApp/mini_hmi/OptionWindow.html
#
# Files generated by GWT 
# 
../htmlApp/translationlayergwt/0DFD596AF51F4CC7A00293FBD296E92A.cache.html
../htmlApp/translationlayergwt/688A00B4C9356DCDA436BE1DA13D5CBA.cache.html
../htmlApp/translationlayergwt/720FBED404E45C61EFEA4E4AD451AB8F.cache.html
../htmlApp/translationlayergwt/8EC125F3977CC8A7FC592AE673DBFB17.cache.html
../htmlApp/translationlayergwt/clear.cache.gif
../htmlApp/translationlayergwt/hosted.html
../htmlApp/translationlayergwt/translationlayergwt.nocache.js

When one of these duplicate resources is loaded as a document into a frame, the system has to pick one of the two instances to load. The spec is squishy about which to pick (it isn't specified), but our impl clearly chooses the wrong one in this case. Both apps are loading 8EC125F3977CC8A7FC592AE673DBFB17.cache.html into a subframe. Since the parent frame's appcache contains the resource its pretty clear that the system should load the resource from the parent frames manifest... but its not doing that.

Similarly when mini_hmi/OptionWindow.html is opened in a seperate window, that should load the resource from the invoking frame's appcache (if present in that cache), but currently its not guaranteed to do that.

To fix this I'll think we'll need to inform the appcache about which document (ultimately the appcache in use by that document) caused the creation of the document being loaded. In the case of a subframe that's the parent document, and in the case of a pop out window it's the opener document. And in the case of starting a shared worker, the invoking document.

Ideally basic <a> tag navigations should also be sensitive to which document initiated the navigation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list