Closed Bug 623996 Opened 14 years ago Closed 14 years ago

Offline Application Cache Breaks with Iframe and Shared Empty Files

Categories

(Core :: Networking: Cache, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b12

People

(Reporter: jkharness87, Assigned: mayhemer)

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 I realize this is obscure, but I wanted to report it since it affected me (and I spent alot of time debugging it) and could be symptomatic of a larger problem with the offline application cache. The offline application cache fails when the following conditions occur: * web page references an empty resource that is included in the manifest * web page has an iframe pointing to a page who also references the same empty resource and has its own application manifest file indicating to cache the resource. Adding any content to the empty resource, such as a comment, fixes the problem. This problem does not occur when caching empty resources by default. It has something to do with the child iframe and sharing the empty resource. Reproducible: Always Steps to Reproduce: 1. Load web page that sources in, for instance a stylesheet, that is empty and has an offline application manifest that specifies to cache the stylesheet. 2. The web page from step 1, has an iframe that sources in another web page that does exactly the same things as the page in step 1. 3. Refresh the page and watch the server logs to see if the resources that should be cached are being requested. Actual Results: Resources that ought to be cached are not (you can see them being requested in the web server logs). Expected Results: The resources are not requested from the web server. Adding any content to the empty file fixes the issue. Also, not doing this via iframes fixes the issue. I have an example web application I will uploaded if bugzilla allows me to. Otherwise, send me an email for the example code.
parent.html illustrates the problem described in the ticket.
I'll check this.
Assignee: nobody → honzab.moz
Cause of the bug: - we are running cache manifest updates one by one, serially - when we are fetching the parent manifest items, all are satisfied from the regular HTTP cache - when we are fetching the child manifest items, empty.css is satisfied from an offline cache entry, as we are getting read access for it (the entry is valid) - but, in nsOfflineCacheDevice::OpenInputStreamForEntry was a bug that didn't allow opening items with zero length (see the fix) - unnecessary failure of this method prevented proper fetching of the entry and failed the whole cache update -> no offline cache was created for the child manifest Please try this [1] build, that contains the fix (should be uploaded soon). [1] http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/honzab.moz@firemni.cz-26f8b759b2d2
Attachment #505108 - Flags: review?(michal.novotny)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #505108 - Flags: review?(michal.novotny) → review+
Comment on attachment 505108 [details] [diff] [review] v1 [Check in comment 5] This is very simple and straight fix, but this bug is not a regression. World won't collapse w/o this fix.
Attachment #505108 - Flags: approval2.0?
Attachment #505108 - Flags: approval2.0? → approval2.0+
Attachment #505108 - Attachment description: v1 → v1 [Check in comment 5]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: