- From: Michael Nordman <michaeln@google.com>
- Date: Fri, 21 Sep 2012 16:08:25 -0700
- To: Andrew Betts <andrew.betts@ft.com>
- Cc: public-fixing-appcache@w3.org
- Message-ID: <CAHpoE=jq3Qfb2_rayzgWfjBSsOsHiNKyCeuFBShm=2TH86g5mQ@mail.gmail.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. > > > > > On Thu, Sep 20, 2012 at 4:04 PM, Andrew Betts <andrew.betts@ft.com> wrote: > >> Just found something today which may be obvious and has simply passed >> me by, but really caught me off guard. It seems that on pages that do >> not reference a manifest and are not themselves in an appcache, >> loading of sub-resources that are appcached may use the appcache, but >> only after checking the network first. If the page does have a >> reference to the manifest (and is therefore appcached as a master >> entry) or is explicitly appcached by another master, the sub-resource >> is loaded from the appcache *without* a network request. >> >> Here's an example: >> >> 1) Page with no manifest attribute, not in appcache (populating >> appcache via IFRAME): >> http://dev.labs.ft.com/andrew/testcases/appcache/1/none-iframe.php >> >> 2) Page with manifest attribute, hence in appcache as master: >> http://dev.labs.ft.com/andrew/testcases/appcache/1/master.php >> >> Load both in Chrome or Safari (Firefox complicates the issue further), >> refresh repeatedly. On the first, both of the coloured paragraphs >> change colour frequently (the CSS file is changing once a second, >> toggling between blue and red). This also happens in the master page >> which is being displayed in the IFRAME. However, in the second >> example, where the master page is loaded as the main page, the colour >> of the first paragraph sticks and remains the same through subsequent >> refreshes, while the second (non-appcached CSS) paragraph continues to >> toggle colour. >> >> Go offline, and in (1) you get a fallback page, while on (2) you get >> the same resource, and in both cases the first paragraph is coloured >> (and obviously remains the same colour until you go back online) and >> the second paragraph is black, because its CSS cannot be loaded and >> wasn't appcached. >> >> For completeness, here's the third scenario: >> >> 3) Page with no manifest attribute, but in an appcache of a different >> master: >> http://dev.labs.ft.com/andrew/testcases/appcache/1/explicit-iframe.php >> >> This exhibits the same behaviour as (2). >> >> There are a number of very bizarre conclusions to this: >> >> - Whether subresource loads check the network before cache is altered >> by whether the page has an associated manifest >> - Whether subresource loads check the network before cache is altered >> by whether the page's IFRAME-parent page has an associated manifest. >> >> Jake - on your flowchart of doom >> ( >> https://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag?slide=81 >> ) >> this behaviour doesn't seem to match what you've documented, so I'd be >> interested to know if you think I'm spouting a load of nonsense here. >> >> Andrew >> >> Andrew Betts [skype:triblondon | @triblondon] >> Director, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs] >> >> -- >> >> ------------------------------ >> 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 Friday, 21 September 2012 23:08:53 UTC