Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detecting whether a navigation was BFCache-eligible #179

Open
fergald opened this issue May 17, 2022 · 2 comments
Open

Detecting whether a navigation was BFCache-eligible #179

fergald opened this issue May 17, 2022 · 2 comments

Comments

@fergald
Copy link

fergald commented May 17, 2022

In order to produce accurate BFCache hit-rate stats a page must be able to tell whether a navigation was even eligible for BFCache in the first place. Currently there is not enough information available from APIs to tell this. Pages which are the result of a session-restore or a tab-clone of a history navigation cannot be distinguished from genuine history navigation.

Steps to demonstrate the issue

  1. go to a page (A) that cannot be BFCached
  2. go to any other page (B)
  3. go back to A
  4. In JS, execute performance.getEntriesByType('navigation')[0].type and you will see back_forward.
  5. clone the tab or quit the browser and restart
  6. In JS, execute performance.getEntriesByType('navigation')[0].type and you will still see back_forward.

Session cookies could be used to detect a session restore. I can't think of anything that could be used to detect a tab-clone.

Should we have something else to indicate that the current navigation is from a session-restore or tab clone?

The proposed not-restored reason API could expose this e.g. by presenting an "ineligible" reason when the last navigation was ineligible for BFCache. Perhaps it would be simpler and more useful to present directly whether the current page came from restore/clone. This would provide more information, in the case where the previous navigation was not back_forward since those navigations are also ineligible regardless of session-restore/clone.

@domenic @yoavweiss

@noamr
Copy link
Contributor

noamr commented May 17, 2022

Does wasDiscurded help you here? This seems somewhat related to #178

@fergald
Copy link
Author

fergald commented Jun 2, 2022

@noamr sorry, I left this unsent for a long time.

I don't think so. I could imagine that it might tell in the case of a session restore (but in my testing with Chrome it is not true on session restore) but for a tab clone, I don't think there would be any expectation that it might be true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants