Intent to Ship: Offline pages for users on slow connections

[ryan...@chromium.org]

Contact emails

ryan...@chromium.org, be...@chromium.org, apo...@chromium.org

Spec

If Chrome determines the network has 2G speeds and there's an offline page stored, Chrome shows the offline page. Chrome’s offline pages are based on MHTML snapshots.

Summary

If a user is on a slow connection and an offline version of the page is available, Chrome will show the offline copy. When the offline copy is shown, the user sees a message at the bottom of the screen that allows them to load the original page. Offline pages can be generated in multiple ways including a user downloading the page or Chrome capturing an MHTML-based snapshot of the page.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Chrome on Android only

Debuggability

Sites can view an offline version of their page by:

1. Navigate to the page in Chrome on Android

2. Open the overflow menu

3. Tap on the download button (arrow in top row of icons)

4. Open the overflow menu

5. Tap on Downloads

6. Tap on the page downloaded

Interoperability and Compatibility Risk

There should be no long-term compatibility risk. If user opt-out for the feature is higher than expected, or if we receive reports of site breakage, we can turn the feature off with no loss to backwards compatibility. All content will still work in all browsers.

Some content, such as javascript, will not work when an offline snapshot is shown. We think this tradeoff is acceptable given that we only do this for slow enough connections that the page has a high probability of failing to load at all. At launch, we expect .02 - .03% of page loads to be affected by Offline Previews. This will change over time as we evolve our triggering logic and how we offline pages.

Interoperability risk:

We are working with the predictability and alignment programs to figure out the best triggering conditions and ways for developers to have some amount of control for the presentation of pages when these triggering conditions are met. We intend to use the real-world user/developer feedback from this launch to inform that work.

We're still evolving our approach to how we offline web pages and plan to share them more broadly to ensure other browsers can support something similar if it is of interest.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5076871637106688

[Rick Byers]

Sorry for the delay.  LGTM1.

This is definitely a different case than most intents, we could debate about how exactly this is or isn't "web exposed" but I don't think it's worth the effort.  Suffice it to say I don't see any non-trivial compat or interop risk here.

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ilya Grigorik]

QQ: how does this interact with Cache-Control? Does this only apply cacheable content, or will we store and reuse content regardless of no-cache, no-store and all the rest? 

[Dimitri Glazkov]

LGTM3

[Ryan Sturm]

>> QQ: how does this interact with Cache-Control? Does this only apply cacheable content, or will we store and reuse content regardless of no-cache, no-store and all the rest? 

To answer your question directly, the feature is not aware of cache directives, but the decision of whether to offline a page is pretty limited.

There are a few ways a user can actually have an offline page to be shown and most of them are manual decisions to offline the page:

Manually:

• from overflow menu
  
• from offline dino page
  
• long press on Zine
  
• long press on any link

Automatically:

• Zine suggestions (launch aiming Q3 or Q4)
  
• Last backgrounded tab
  

The goal is to provide users an offline page in the cases where it seems pretty safe. The last backgrounded tab case helps with keeping the tab in a state where it doesn't need a network reload, which is not perfect, but could provide a better experience for a slow network user.

[Ilya Grigorik]

Gotcha, thanks Ryan!

[Lucas Garron]

I'm strongly concerned about the security UI behaviour of this change, and I'm very uncomfortable shipping an automatic offline fallback until offline pages support caching HTTPS validation.

If I understand correctly, this change will non-deterministically result in dropping all security UI for a page load, even if the user made an HTTPS request. There will literally be no way for the user to tell if the content was transferred securely. In fact, given the UI right now I'm not even confident that an HTTPS page will not fall back to an page cached from HTTP behind the scenes. (Users might like that behaviour, but it's our responsibility to make sure we do the secure thing.)

The currently offline UI glosses over important differences between HTTPS and HTTP. In particular, the omnibox completely removes the the scheme, and select+go on the omnibox will visit the HTTP version of a page, which may even have different content or redirect elsewhere (this actually happens for http://example.com, which redirects to http://www.example.com).

The situation already uncomfortable when the user explicitly opens a download, but an automatic fallback would break tranquility to a significant new extent.

I recall hearing that there were plans to cache security info; is there a bug or a writeup that documents what happened to those plans?

»Lucas

[Dmitry Titov]

Just to follow up, we are having some offline conversations with security team members (including Lucas) to carefully look back at the Offline UI and how it displays page info. It was reviewed and shipped a few months ago, however if there are doubts we should always go back and see if the UI can be improved. At the moment, there is no results yet, we'll update the group on this specific aspect as soon as we have a better understanding and perhaps a plan.

In general, offline pages are static snapshots and we are trying to communicate to the user that they are not original page (which can be HTTP or HTTPS) but merely a snapshot. This not only indicates that those snapshots are not trusted, but also to avoid confusion about why they are not interactive (no JS nor network requests, form controls are disabled etc). Ideally, they are shown as a better recourse instead of a network error page of some sort when connection to a real page is not possible.

Having said that, we are always looking into how we can improve the UI here and avoid user confusion. 

Thanks!

Dmitry

[Brian Haak]

As a mobile web developer, I manage the state of my web page in JavaScript. I check the connectivity and connection speed using WebSockets, and all communication goes thru those (including the REST over WebSockets protocol).

Unfortunately, the feature you've implemented renders our web app completely unusable after going to the "Offline" mode.

Steps to reproduce:
1. Open my web app (please, note, that I'm using the "cache-control:private, max-age=0, no-cache, no-store, must-revalidate" header to completely disable caching).
2. Turn off radio (go to the airplane mode).
3. Close Chrome browser in the task screen.
4. Launch Chrome again.
5. See the "Offline" in the place of HTTPS certificates area.
6. Enable radio (turn off the airplane mode).
7. Wait any infinite amount of time, or press the "Refresh" button, nothing renders our web app working again.

Moreover, your wonderful MHTML doesn't save any JavaScript, so the offline page stops working completely.
We're using scrolling library in JavaScript, so our users can't scroll the page, can't navigate to subpages in our
Single-Page App (SPA).

So, the feature breaks the operation of the web app (virtually, any web site using JavaScript).

Is there any way to tell Chrome to not store the MHTML version and just display that the page is not available when opened from offline mode - the same way as it was working before?

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. SSP is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.