On Mon, Sep 11, 2023 at 8:46 AM 'Fergal Daly' via blink-dev <
blink-dev@chromium.org> wrote:
>
>
> On Fri, 8 Sept 2023 at 02:21, Vladimir Levin <vmp...@chromium.org> wrote:
>
>> This is potentially a naive question, since I'm not familiar with all of
>> the CC headers, but how would the following situation work (or rather how
>> is this meant to work?):
>>
>> I have an "overview" page that lists some items that come from a
>> database. This page has an input box with a button to add a new item. The
>> way the button works is it POSTs to the same page to add an entry into some
>> database, and then redirects to a new "details" page. The "overview" page
>> also currently sends CCNS, so that when the user clicks back from the
>> "details" page, they see an updated list which was re-fetched from the
>> server. Without CCNS, going back hits BFCache and the list is not up to
>> date.
>>
>
> That seems correct and is a problem with BFCache in general. E.g. you hit
> back and your shopping cart has the wrong number of items.
>
>
>> Is there a simple solution to this if CCNS doesn't prevent BFCache?
>>
>
> The one-size-fits-all solutions is something like
>
> addEventListener("pageshow", e => {
> if (e.persisted) {
> document.body.innerHTML = "";
> location.reload();
> }
> })
>
> Which is not great for users but also not terrible, the time to load will
> be increased by the duration of a BFCache restore which is mostly < 100ms
> and much less on a fast device.
>
I suspect that this will defeat things like paint holding. That is, the
behavior of non-bfcache load is to typically to show the painted output of
the last page while the navigation commits and shows a frame of the new
page (within timeout limit). With this script, this will quickly show a
blank page (at the speed of BFCache restore + one frame), and then begin
the reload().
So although I agree with your timing estimates, I think the behavior would
look substantially worse than just a 100ms delay.
>
> The better UX would be to have a `pageshow` handler that refreshes just
> the data that needs refreshing. The difficulty of doing that is heavily
> dependent on the site design,
>
That's a fair point. This seems non-trivial though :)
>
> F
>
>
>> This is a toy example:
>> https://rocky-merciful-creek.glitch.me/nostore/one.html?nostore=1
>> if you click the link and go back, the number changes. If query nostore=0
>> then it doesn't. The query parameter just controls whether CCNS is sent
>>
>> Thanks!
>> vmpstr
>>
>>
>>
>> On Thu, Sep 7, 2023 at 5:40 AM 'Mingyu Lei' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> (Not to answer how the 3 minutes was originally decided, but just to
>>> share a bit of the context.)
>>>
>>> The default BFCache timeout was set to 3 minutes on Chrome for a long
>>> time. Only after Sep 2022, it was increased to 10 minutes after evaluating
>>> the hit rate improvement and other impacts (https://crbug.com/1305878).
>>> For CCNS pages, we will follow the old timeout of 3 minutes, or in other
>>> words, the changes that increase BFCache timeout from last year won't be
>>> applied to CCNS pages.
>>>
>>>
>>> On Thu, Sep 7, 2023 at 12:21 AM Daniel Bratell <bratel...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for your answers. I think we are on the same page since I too
>>>> consider this to be of high value to users. The difference in perceived
>>>> performance is so large that I understand that it is worth adding some
>>>> magic for.
>>>>
>>>> On the other hand, as you also know, there is a risk and I want to be
>>>> sure that it is fully understood. You have mentioned a shorter timeout a
>>>> couple of times, and the explainer says it will be 3 minutes instead of the
>>>> default 10 minute cache timeout. I'm well aware of sites that time out
>>>> authentications server side after a couple of minutes of inactivity and I
>>>> guess 3 would be in the same ball park. Did you pick that particular number
>>>> for any particular reason. Is it the lowest number that still gives any
>>>> benefits?
>>>>
>>>> /Daniel
>>>> On 2023-09-01 10:05, 'Fergal Daly' via blink-dev wrote:
>>>>
>>>> Sorry for the slow reply, I've had to focus on some other things in the
>>>> last month. The reply below covers a few overlapping topics that were
>>>> brought up in this thread by Yoav Weiss and Daniel Bratell.
>>>>
>>>>
>>>> On Sat, 29 Jul 2023 at 03:03, Mike Taylor <miketa...@chromium.org>
>>>> wrote:
>>>>
>>>>> Thanks for the additional analysis. Another question I have, if a site
>>>>> sends:
>>>>>
>>>>> "Cache-Control: no-cache, no-store, must-revalidate" (copypasta from
>>>>> https://stackoverflow.com/a/2068407),
>>>>> would it be treated differently as "Cache-Control: no-store"? I'm trying
>>>>> to think of signals that might be useful as
>>>>> heuristics for "no seriously don't ever cache this"...
>>>>>
>>>>>
>>>> We would prefer not to do this and other browsers are in agreement
>>>> <https://github.com/whatwg/html/issues/5744>. If we give any kind of
>>>> simple header that prevents BFCaching, it will become the wide-spread
>>>> stack-exchange-documented way to opt out of BFCache. Any site that truly
>>>> cannot tolerate its data entering BFCache and doesn't already fall under
>>>> one of our conditions for avoiding BFCache, can erase content in a
>>>> `pagehide` handler as they enter BFCache and reload it in a `pageload`
>>>> handler if restored. This is pretty simple to do for anyone who truly
>>>> needs it
>>>> (worst case they trigger a reload from JS when leaving BFCache,
>>>> obviously not a good user experience but we have to weight that against
>>>> block BFCache for many users) but it still provides a little bit of a
>>>> barrier, so hopefully people think twice and instead correctly support
>>>> BFCache rather than casually opting out,
>>>>
>>>> F
>>>>
>>>> On 7/27/23 9:04 AM, Mingyu Lei wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> Following our previous response, we would like to share the usage data
>>>>> that we have collected from the beta channel. 18.76% of history
>>>>> navigations
>>>>> are not restored from BFCache because of the CCNS header only. The
>>>>> following are the breakdowns:
>>>>>
>>>>> - No RPC containing CCNS response header: 8.63%
>>>>> - *No cookie modification: 6.70%*
>>>>> - With non-HttpOnly cookie modifications only: 1.38%
>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 0.55%
>>>>> - With RPC containing CCNS response header: 10.13%
>>>>> - No cookie modification: 1.01%
>>>>> - With non-HttpOnly cookie modifications only: 7.86%
>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 1.26%
>>>>>
>>>>> Based on these figures, we will update the proposal to evict the
>>>>> BFCache entry with any cookie modification for the current phase. This
>>>>> should give us 6.70% improvement in cache hit rate.
>>>>>
>>>>> We could continue the HttpOnly cookie discussion in the future.
>>>>>
>>>>> On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei <le...@google.com> wrote:
>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> Thanks for the comments. We have discussed the concerns you raised
>>>>>> before and please find the replies below.
>>>>>>
>>>>>>
>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>> cookies.
>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute
>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something
>>>>>>> else?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> Later in
>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>
>>>>>>
>>>>>> The short answer is that we will only monitor HttpOnly cookies,
>>>>>> regardless of whether they are secure or not. The terms in the explainer
>>>>>> were unclear, and we will fix them.
>>>>>>
>>>>>> I see that
>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>> references this work. Did we learn anything from experimentation in the
>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>
>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>> returned
>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>> surprised
>>>>>>> if we don't have UMA for that... perhaps just globally would be useful
>>>>>>> to
>>>>>>> consider).
>>>>>>>
>>>>>>
>>>>>> We are currently conducting a Finch experiment to collect the hit
>>>>>> rate on beta, and the data will be available next week. We will share it
>>>>>> with you again after we have the data.
>>>>>>
>>>>>> With that data, we will be able to tell the percentage of page loads
>>>>>> that observe HttpOnly cookie changes, any cookie changes, or no cookie
>>>>>> changes. There will also be another dimension about whether the page had
>>>>>> sent out RPC with CCNS response. There is no pre-existing UMA for this,
>>>>>> but
>>>>>> we have recorded the reasons why BFCache is not restored.
>>>>>>
>>>>>> My only concern (which may not be grounded in reality) would be for
>>>>>>> sites not following best practices...
>>>>>>
>>>>>>
>>>>>> We expect that there will be cases where pages are restored
>>>>>> inappropriately where sites are not following good practice. We don't
>>>>>> have
>>>>>> an idea of the size of this problem. We will have data from the beta
>>>>>> channel soon that will tell us what the difference would be in terms of
>>>>>> BFCache hit-rate between *monitoring all cookies* and *only
>>>>>> monitoring HttpOnly cookies*. Our thought process looks like this:
>>>>>>
>>>>>> If *monitoring all cookies* already gives us large hit-rate
>>>>>> improvement, *or* the difference between *monitoring all cookies*
>>>>>> and *only monitoring HttpOnly cookies* is small, then we are happy
>>>>>> to just be conservative and go with *monitoring all cookies*.
>>>>>> Otherwise*, we would like to discuss this further.
>>>>>>
>>>>>>
>>>>>> ** "Otherwise" means monitoring all cookies will only give us
>>>>>> negligible cache hit-rate improvement, and monitoring HttpOnly cookies
>>>>>> will
>>>>>> give us a much larger increase.*
>>>>>>
>>>>>> Thanks,
>>>>>> Mingyu
>>>>>>
>>>>>> On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor <miketa...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:
>>>>>>>
>>>>>>> [BCC chrome-bfca...@google.com]
>>>>>>>
>>>>>>> On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com> wrote:
>>>>>>>
>>>>>>>> +chrome-bfcache <chrome-bfca...@google.com>
>>>>>>>>
>>>>>>>> On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Contact emails kenjibah...@chromium.org, fer...@chromium.org,
>>>>>>>>> denom...@chromium.org, le...@chromium.org
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>
>>>>>>>>> Design docs
>>>>>>>>> https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit?usp=sharing
>>>>>>>>>
>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>
>>>>>>>> This is a really well-written explainer, thank you!
>>>>>>>
>>>>>>> One point of clarification:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>> cookies.
>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute
>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something
>>>>>>> else?
>>>>>>>
>>>>>>> Later in
>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>
>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> A behavior change to safely store (and restore) pages in the
>>>>>>>>> Back/Forward Cache despite the presence of a "Cache-control:
>>>>>>>>> no-store" HTTP
>>>>>>>>> header on HTTPS pages. This would allow pages to enter BFCache and be
>>>>>>>>> restored as long as there are no changes to cookies or to RPCs using
>>>>>>>>> the
>>>>>>>>> `Authorization:` header.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blink component UI>Browser>Navigation>BFCache
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache>
>>>>>>>>>
>>>>>>>>> Search tags bfcache
>>>>>>>>> <https://chromestatus.com/features#tags:bfcache>
>>>>>>>>>
>>>>>>>>> TAG review
>>>>>>>>>
>>>>>>>> I see that
>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>> references this work. Did we learn anything from experimentation in the
>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> TAG review status Not applicable
>>>>>>>>>
>>>>>>>>> Risks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>
>>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>> returned
>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>> surprised
>>>>>>> if we don't have UMA for that... perhaps just globally would be useful
>>>>>>> to
>>>>>>> consider).
>>>>>>>
>>>>>>> My only concern (which may not be grounded in reality) would be for
>>>>>>> sites not following best practices...
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> *Gecko*: No signal
>>>>>>>>>
>>>>>>>>> *WebKit*: No signal
>>>>>>>>>
>>>>>>>> Can we request signals?
>>>>>>>
>>>>>>>
>>>>>>>>> *Web developers*: No signals
>>>>>>>>>
>>>>>>>>> *Other signals*:
>>>>>>>>>
>>>>>>>>> WebView application risks
>>>>>>>>>
>>>>>>>>> Does this intent deprecate or change behavior of existing APIs,
>>>>>>>>> such that it has potentially high risk for Android WebView-based
>>>>>>>>> applications?
>>>>>>>>>
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debuggability
>>>>>>>>>
>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No
>>>>>>>>>
>>>>>>>>> BFCache is not supported on WebView, so this change has no impact
>>>>>>>>> there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>> ? No
>>>>>>>>>
>>>>>>>>> Flag name on chrome://flags
>>>>>>>>>
>>>>>>>>> Finch feature name CacheControlNoStoreEnterBackForwardCache
>>>>>>>>>
>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>
>>>>>>>>> Tracking bug
>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1228611
>>>>>>>>>
>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4251651
>>>>>>>>>
>>>>>>>>> Estimated milestones
>>>>>>>>> DevTrial on desktop 116
>>>>>>>>> DevTrial on Android 116
>>>>>>>>>
>>>>>>>>> Anticipated spec changes
>>>>>>>>>
>>>>>>>>> Open questions about a feature may be a source of future web
>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known
>>>>>>>>> github issues in the project for the feature specification) whose
>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to
>>>>>>>>> naming
>>>>>>>>> or structure of the API in a non-backward-compatible way).
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>> https://chromestatus.com/feature/6705326844805120
>>>>>>>>>
>>>>>>>>> Links to previous Intent discussions
>>>>>>>>>
>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>
>>>>>>>> --
>>>>>>> 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+unsubscr...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>> --
>>>> 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+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> --
>>> 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+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%40mail.gmail.com.
