- From: Rakina Zata Amni <notifications@github.com>
- Date: Thu, 23 Mar 2023 19:02:37 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/417/1482147706@github.com>
> Thanks for raising this. I think it's reasonable to make pages that own the clipboard with lazy data non-bfcacheable. It shouldn't come up very often. > Edit: to clarify, I don't think a page holding the clipboard can be allowed into bfcache because if the user tries to paste, we we have no way to resurrect the page so the paste will fail. This is just like a page having an unload handler, which I presume prevents deactivation. New APIs shouldn't make pages non-bfcacheable. It will either make the user experience worse by making history page load times worse (as it could've been instant), or it will make web developers not want to use the API because they want to avoid losing the instant load. We've disabled BFCache on old APIs, but that's to prevent existing pages from breaking because they didn't expect the page to be BFCached and the API to behave differently. I think the API here should behave the same way on navigation, regardless of whether the document got bfcached or not. Whether we drop the contents on normal navigations or immediately do the work then, I don't see why we can't do that on navigations where we bfcache instead. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/417#issuecomment-1482147706 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/417/1482147706@github.com>
Received on Friday, 24 March 2023 02:02:50 UTC