- From: Andrew Betts <andrew.betts@ft.com>
- Date: Mon, 24 Sep 2012 00:36:12 +0100
- To: Michael Nordman <michaeln@google.com>
- Cc: public-fixing-appcache@w3.org
- Message-Id: <615714D4-BFB6-47F5-8277-C8886E1C8048@ft.com>
> Yup, the memcache is confounding things. Here's another page to add to your suite. This one avoids the subresource cross-talk between a parent that's not appcached and a child that is. > > <html> > <h3>Loading master in IFRAME w/o loading any subresource in the parent FRAME.</h3> > <iframe src="http://dev.labs.ft.com/andrew/testcases/appcache/1/master.php" style="width: 600px; height: 200px; border: 1px solid black;"></iframe> > </body> > </html> > > > > On Fri, Sep 21, 2012 at 1:54 PM, Michael Nordman <michaeln@google.com> wrote: > Looks like these pages demonstrate a bug in chrome. Regardless of what frame it's placed in, http://dev.labs.ft.com/andrew/testcases/appcache/1/master.php should behave as it does when loaded into a top-level tab where the appcached style is unmodified across reloads. The behavior when loading that page in isolation looks spec-compliant. But that ain't happening in the nested case where the containing page is expected to use an non-appcached version of the style. > > I think this may have to do with webkit's memory cache. That cache is consulted prior to to consulting the appcache. I suspect the presence of the non-appcached entry in that memory cache is getting in the way of loading the appcache version but need to look more closely in a debugger to really verify that. Thanks Michael. Do you have a webkit bug reference, or do you want me to file one? -- ------------------------------ This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723.
Received on Sunday, 23 September 2012 23:36:36 UTC