Re: prefer-online vs manifest association

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.
>
>