Contact emails
Requesting approval to ship?
No.--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALHg4nnwifzfCtSq_oc8eC5xc%3Doa19RzJ81JwUAfQd%2BKOq%3DaTA%40mail.gmail.com.
On 1/15/19 12:09 AM, Daniel Bratell wrote:
> This is awesome! It was a feature we had in Presto (and in early versions of Chromium based Operas but we dropped it to focus on other things) and I
> have missed it.
>
> As you notice it is possible to confuse pages that don't expect to ever get any more events after a click on a button for instance. There will need to
> be an education effort included with the release, and as you write in the design document, a document today can have a lot of external tentacles that
> might make it harder to have it enabled.
>
> On the other hand onfreeze/onsuspend handlers will give the browser a hint that the page knows how to quickly resume itself. Hopefully not with a full
> reload().
FWIW, pagehide/pageshow events are the ones designed for bfcache. But sure, freeze/suspend work quite similarly.
-Olli
>
> /Daniel
>
> On Mon, 14 Jan 2019 19:54:32 +0100, Alexander Timin <alt...@chromium.org> wrote:
>
> Sorry for the confusion, the one-pager link is incorrect (it points to another bfcache-related document), here's the correct one
> <https://docs.google.com/document/d/1mrgp7XzR16rd1xqFYOJgC1IP0NPLZFaRU5Ukj3-TlLw/edit#>.
>
> On Mon, 14 Jan 2019 at 18:45, Alexander Timin <alt...@chromium.org <mailto:alt...@chromium.org>> wrote:
>
> Contact emails
>
> alt...@chromium.org <mailto:alt...@chromium.org>, bfcac...@chromium.org <mailto:bfcac...@chromium.org>
>
> *Design doc*
> One-pager <https://docs.google.com/document/d/19u1jg934oNwE6IzZQ-vkeZLVqQiQWdZSkgTWkzp0CmU/>.
> bfcache and Chrome <https://docs.google.com/document/d/1YrBKX_eFMA9KoYof-eVThT35jcTqWcH_rRxYbR5RapU/>.
>
> *Very high-level summary*
> Implement in-memory cache for pages to make back/forward navigations to previously visited pages instant.
>
> *Risks*
> *
> *
> *Interoperability and Compatibility*
> Medium risk. While other browsers already have back-forward cache implementations, they all are subtly different. It's likely that the
> Chrome's behaviour of navigation-related event listeners will change, especially for unload(). There is a low-to-medium risk of breaking
> existing websites.
>
> *Edge: *shipped
> *Firefox: *shipped <https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Working_with_BFCache>
> *Safari: *shipped <https://webkit.org/blog/427/webkit-page-cache-i-the-basics/>**
> *Web / Framework developers: *Mixed signals, generally positive
>
> Ergonomics
> No risks, this feature improves ergonomics.
>
> Activation
> Feature is enabled by default.
>
> Debuggability
> We would consider adding DevTools support based on the developer feedback.
>
> Will this feature be supported on all six Blink platforms?
> Yes.
>
> Is this feature fully tested by web-platform-tests?
> Still under consideration. We're not sure if a good way to test the feature exists.
>
> *Feature dashboard entry*
> https://www.chromestatus.com/feature/5815270035685376
>
> Requesting approval to ship?
>
> No.
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org
> <mailto:chromium-dev...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALHg4nnwifzfCtSq_oc8eC5xc%3Doa19RzJ81JwUAfQd%2BKOq%3DaTA%40mail.gmail.com
>
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CET (UTC+1) */
>
> --
> 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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zvmnuwprrbppqq%40cicero2.linkoping.osa
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zvmnuwprrbppqq%40cicero2.linkoping.osa?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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8eee25ca-0656-9c18-3105-a4027121b956%40welho.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi_-ecT2Zvn4qv5Tv_3WfHEDK3CaNO76dSPzMiXxaCgnnQ%40mail.gmail.com.
Can you please file a full launch tracking bug? I want to make sure security does a full review (how will this interact with site isolation), and privacy (how will clearing the cache or cookies affect pages in the cache)?
On Mon, Jan 14, 2019 at 7:46 PM Alexander Timin <alt...@chromium.org> wrote:
> Medium risk. While other browsers already have back-forward cache implementations, they all are subtly different. It's likely that the Chrome's behaviour of navigation-related event listeners will change, especially for unload(). There is a low-to-medium risk of breaking existing websites.
Did you write web-platform-tests? This is definitely an area that
could use more tests and perhaps also some refactoring in the HTML
Standard. (Also to exactly define the timing of the new events
mentioned elsewhere in this thread.)
On Tue, Jan 29, 2019 at 4:22 PM Alexander Timin <alt...@chromium.org> wrote:
> We're very early in the development cycle, so not yet.
>
> I've been thinking about how web-platform-tests could look like for this, but I don't think
> that we can do anything particularly smart here given that browsers can implement bfcache or not.
> The best I can think of is to check that the set of fired listeners is reasonable (there should be
> two sets which we can accept — one for regular navigations with tearing down the page when we navigate away
> and the second for bfcache).
>
> I'm also very interested in hearing the ideas here.
I think everyone implements bfcache at this point so writing tests
that assume it's implemented seems fair. User agents already need ways
to disable tests so they could ignore these if they're not relevant.
Allowing multiple passing conditions doesn't seem like a good idea as
then you're never quite clear what was actually tested without a lot
of additional investigation.
Has there been any thought into how this will interact with service worker fetch handling.--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To post to this group, send email to bfcac...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/f79d3e31-13d1-4f2e-b92a-e2bd4cc9b1be%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To post to this group, send email to bfcac...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/d1e3037e-062c-4091-aaa0-988a529035ca%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To post to this group, send email to bfcac...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/ee8586c6-4d2d-4a43-b540-4ea742a16b23%40chromium.org.
How does bfcache cope with, if page js does not respond to navigation events per spec?
--
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CABg10jxTi24XfzSeDOc%2BBzjc%3DdTVsGKKEjbe6iyLJA7cXQo5hg%40mail.gmail.com.
(1) how to suspend/freeze each frame's js execute state is very tricky, chromium M56+ has refactored source code to use T& instead of T*, which causes a lot of crashes on back-restore...
(2)pagecache MUST be occupied with AdBlock, since many 3rd ads use iframes to load ad contents, if not filtering them, may cause a lot of problems
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/7274618d-5465-4f39-9d68-06b3407cb278%40chromium.org.
(1) in what version of Chrome will this functionality become available (or, if that isn't yet known, what the approximate time frame is),
(2) will setting the http cache-control header to "no-cache, no-store, must-revalidate" be sufficient to disable bf caching -- we have an app that breaks if bf caching is enabled, and
(3) how can I get access to pre-release version of chrome to verify that our bfcache disabling is working?
Can someone on the Google team working on the bf cache functionality provide any information on:
(1) in what version of Chrome will this functionality become available (or, if that isn't yet known, what the approximate time frame is),(2) will setting the http cache-control header to "no-cache, no-store, must-revalidate" be sufficient to disable bf caching -- we have an app that breaks if bf caching is enabled, and(3) how can I get access to pre-release version of chrome to verify that our bfcache disabling is working?
Thanks,
MS
--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To post to this group, send email to bfcac...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/699d145c-1d1b-46e1-94e2-3ec458a2795f%40chromium.org.
Thanks for the info, Kentaro.MS
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/e5122641-a638-43eb-9123-3fd2426584f0%40chromium.org.
Hi Arthur,Thanks for pointing us to those page events. When we do our testing once bfcache is included in canary, we will give that a try.
-Michael
On Friday, March 29, 2019 at 11:10:53 AM UTC-5, Arthur Sonzogni wrote:Hi Michael & Mark,If you want to remove the spinner from the previous document when the user navigate back to it, you can do:~~~window.addEventListener("pageshow", function(event){ remove_spinner() );
~~~For reference, here is a presentation about the Page Lifecycle API:Other browsers like Firefox have a BackForwardCache, does this solution fixes your problem?
Le vendredi 29 mars 2019 15:15:55 UTC+1, Michael Villere a écrit :Hi Alexander,I am one of Mark's colleagues, and he asked me to take a stab at responding to your question.Our app is an education product, used by K-12 students in schools. Students use a skinned (based on their grade) single page app to receive assignments and navigate their personalized learning path. Curriculum materials, like lessons and tests, are hosted independently of the Student SPA, because our curriculum materials are shared across all of the company products. So, when a student wants to study a lesson or review a test, they are handed off to one of the curriculum services in order to do so.The problem with bfcache occurs because the hand off to the curriculum service takes a moment and so prior to the hand-off while waiting for the browser to transition to the new page served by the curriculum service, we hide the content of the SPA and show a loading spinner. This is important for kids, especially younger kids, because they are often very antsy and tend to click randomly and rapidly while they are waiting for pages to load.If bfcache is enabled, and the student clicks the back button to return to the SPA from the curriculum service (instead of the normal save/exit button flow), then the page they return to is the SPA that was wiped away and replaced with a loading spinner. I suppose we could try to detect that bfcache was being hit, not sure if that is even something that is technically doable, and then try to trigger a page reload at that point or try to re-display the learning path (which usually needs to be refreshed due to work that the kid did), but we decided it is more straight forward just to eliminate this from occurring by disabling bfcache.Most of the time, when the student is returning from the curriculum service, the state of their learning path has changed and needs to be recalculated anyway, so a page reload is the appropriate thing to do at that point. So the bfcache basically gets in the way of our recalculations. It should also be noted that because we are an educational product and dealing with school age kids, a lot of our progress / scoring calculations need to remain on the server to prevent cheating.Let us know if you need more information or want to see the workflow in action. We are happy to participate in the process. Thanks for your help.-Michael
To unsubscribe from this group and stop receiving emails from it, send an email to bfcac...@chromium.org.
To post to this group, send email to bfcac...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/e5122641-a638-43eb-9123-3fd2426584f0%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a3c6a2b-de0e-468a-8f96-76b03a2fb629%40chromium.org.