Allow automatic use of stale cache entries if site is unreachable.

Allow automatic use of stale cache entries if site is unreachable.

BUG=2204
R=rvargas@chromium.org

[Randy Smith (Not in Mondays), 2013-01-28 19:24:31]

Ricardo: This change is obviously not ready for review (look at all the debug
code and the lack of new tests :-}) but the basic outline is here.  Willing to
take a look and give me your perspective?

Specific questions:
* Is this the right general way to implement this feature?  I'm trying to have
an offline network error code trigger a read from cache without re-validating
the cache the way a 304 would.

* Do you have any suggestions as to how I could extend this to redirects? 
Redirects aren't read from cache because they don't allow conditionalization of
the headers, which means the mode is set to WRITE in BeginCacheValidation, which
disallows reads when we get a failure from the net requests.  I tried to solve
that with a hammer (by not setting the mode to WRITE until we've gotten the net
request back and confirmed we don't want to follow the offline path) but then I
get a crash when dealing with redirects in DoCacheReadMetadata in allocating the
IO buffer.  (I can upload that patch if you want to look at it.)

Thanks much in advance for your advice.

[Randy Smith (Not in Mondays), 2013-01-29 20:39:04]

Ricardo: I think I figured out how to do redirects properly.  Now I'm *very*
curious as to what you think.  If you think this is a reasonable direction, I'll
grok the test framework and throw together some tests, and ask for a real
review.

[rvargas (doing something else), 2013-01-29 22:04:28]

I'm sorry for the delay.

I'm curious as to why do we want to start with the network and only go to the
cache if that fails. A more natural approach would be to use
LOAD_ONLY_FROM_CACHE right from the start when offline mode is selected. Should
we detect offline status at a higher level and switch to load only from the
cache after that point (at least on a per page basis)? I'm concerned about
having the granularity of the decision at the request level, and having it
engaged all the time.

I have serious doubts about being able to implement offline mode in a totally
transparent way. There's a significant group of requests that have a no-store
header and it's hard to predict what that would do to a page when attempting to
display it offline, and that would indicate that the user should actively select
to force loading a page when offline. I much rather (as a user) have a way to
record/replay particular sites that I know I'll be using later (maybe with the
caveat that if something was not recorded there may be broken stuff if I try to
replay that site). In that case, the record action is a clear indication to
store everything :) (but still, some sites will not work!)

BTW, isn't this something that can be implemented instead as an extension? I
mean, by us, but not as a core feature of the browser (seems like one of those
things that is used/usable by a small percentage of our users).

I hope I'm not derailing you too much!

[Randy Smith (Not in Mondays), 2013-01-29 22:36:41]

On 2013/01/29 22:04:28, rvargas wrote:
> I'm sorry for the delay.

No worries; thanks for the response!

> I'm curious as to why do we want to start with the network and only go to the
> cache if that fails. A more natural approach would be to use
> LOAD_ONLY_FROM_CACHE right from the start when offline mode is selected.
Should
> we detect offline status at a higher level and switch to load only from the
> cache after that point (at least on a per page basis)? I'm concerned about
> having the granularity of the decision at the request level, and having it
> engaged all the time.

So if we're actually going to implement an offline *mode*, that would be the
natural and right way to do it.  My preference is not to be modal, but instead
do something that does best effort for the user in whatever state we're in.  A
minor use case is one where you have access to a subset of the internet but not
the whole thing (could happen on either the inside of the outside of a corporate
firewall).  But the thing that drives me more is just simplicity--I think we can
provide as good or better user experience without making the user actually go
into offline mode.

But part of my thought about putting this behind a flag is to implement it, then
enable the flag and play with it for a while, and try to get a sense of the ways
in which is completely falls over :-}.

> I have serious doubts about being able to implement offline mode in a totally
> transparent way. 

Completely agreed.  I'm trying to do something that'll be useful in many cases,
and no worse in the remainder.

> There's a significant group of requests that have a no-store
> header and it's hard to predict what that would do to a page when attempting
to
> display it offline, and that would indicate that the user should actively
select
> to force loading a page when offline. 

I had been assuming no-store pages don't go into cache, and hence won't be
retrievable, and hence won't cause us those kind of problems.  I presume there's
something I'm over-simplifying?

> I much rather (as a user) have a way to
> record/replay particular sites that I know I'll be using later (maybe with the
> caveat that if something was not recorded there may be broken stuff if I try
to
> replay that site). In that case, the record action is a clear indication to
> store everything :) (but still, some sites will not work!)

So my current vision is to do this in stages: Do the basic change, so that if we
try to access something and it's not accessible but we have it in cache, throw
it up with a signal in the omnibox (and maybe a butterbar--I'll need to chat
with ui-leads about that) that it's a stale cache entry.  Then create an
extensions interface (probably through AppCache, but I'm so far clueless about
AppCache, so don't take that seriously) that allows for users to "pin"
particular pages in cache.  And that'll have a really simple UI which is
effectively a single radio button in the omnibox.  But I'm getting way ahead of
myself.

And yes, some sites won't work.  I have no illusions about that.  This is not,
at all, a replacement for the offline support in HTML 5, and there are sites
that won't work well at all without that support.  But I'm very curious as to
how far we can get with something simple; I suspect many sites will "just work"
and that that would be really nice for our users.

FWIW, my personal use case is docs.python.org.  I think that'll work fine :-}.

> BTW, isn't this something that can be implemented instead as an extension? I
> mean, by us, but not as a core feature of the browser (seems like one of those
> things that is used/usable by a small percentage of our users).

Well, I'm torn.  I suspect it'd be much much harder to implement this in an
extension, and that I'd be duplicating cache functionality.  And my image of a
non-modal interaction pattern would be even harder than that; I might need to
duplicate the entire cache.  But I hear you that we don't want to put a lot of
code into the browser for something we don't know how valuable it'll be to our
user base.  I'm still hopeful that this isn't going to be very much code :-}.

And I do think offline, especially but so not only for mobile, is an area where
we've really not put a lot of time and engineering effort, and that a fair
number of people would value having a unified offline experience.  I don't think
that this'll particularly do that, but it's a piece in the puzzle.  

If it helps any, Darin and I have had conversations (not recently) in which he
supported Chrome just reading from cache if the browser was offline.  Just one
person's opinion, but a reasonably clueful person.

> I hope I'm not derailing you too much!

Not at all; this is all stuff it's really worth working through, and I
appreciate the engagement.

I've thrown a lot of text at the screen above, so let me summarize my current
plan shortly:

* Under a flag, allow the cache to automatically respond with cached information
if, on a per-website basis, we can't reach that web site.  The auto-response is
to reduce modality and "just do the right thing" for the user if we can.  The
per-website basis is to manage the changing networks changing website
accessibility issue.

* Play around with that a bit (maybe share with chromium-dev and ask for
experimentation) to figure out when it works nicely, when it fails badly, and
how it fails when it fails badly.  Tweak as needed

* Enable outside the flag if that experiment makes us think it'll improve user
experience.  This will require adding UI to let people know what's going on.

* Implement some extension API to allow for "pinning" of pages in the cache. 
Currently thinking through AppCache, but the idea's pretty unformed at this
point.

* Write a simple extension that allows users to pin specific files.

* Let extension developers do the rest :-}.

Let me know what you think.

[Randy Smith (Not in Mondays), 2013-01-29 22:40:15]

Ricardo: What would you think of moving this discussion over to the bug?  The
level we're talking at seems more appropriate to design/requirements than code.

[rvargas (doing something else), 2013-01-30 03:12:44]

On 2013/01/29 22:40:15, rdsmith wrote:
> Ricardo: What would you think of moving this discussion over to the bug?  The
> level we're talking at seems more appropriate to design/requirements than
code.

I'm totally fine with moving to the bug.

Play with it: that's totally reasonable, and that's what I thought you were
doing :)

Extension: No, I don't mean to reimplement it. If there's no API to do that,
that would mean adding the API to actually load stuff from the cache with the
right flags. Yeah, mobile is an issue because the lack of extensions on the
platforms were this would be most useful...

no-store: I would actually expect a kind of random distribution of no-store
resources on otherwise cacheable pages, but I have no data to back that up.

Overall my main concern is the detection/retry at the resource granularity (and
at the lowest possible layer). Even if you want transparent, mode-less
operation, I would have expected an upper layer to detect the desired condition
and reissue the proper requests with the new flags. I guess I don't understand
clearly the model of starting loading a page and ending with some resources from
the cache and some from the net, if the connection goes on and off. I don't know
what to say that to the user.

In other words, "load from the net if possible, otherwise from the cache" is
something that makes sense at the page level, but I'm not so sure it does at the
request level. If I know that I'm offline, why keep retrying the 80 requests
that this page has instead of showing everything quickly?