docs(bfcache): add note about Back/Forward Cache (BFCache) limitations and default behavior#41872
Conversation
This patch adds documentation that warns about the navigation bein broken, if the browser is forced to use bfcaching to restore page on navigation. Helps devs realize issue when working with bfcached pages.
@microsoft-github-policy-service agree |
| :::warning | ||
| **Testing Back/Forward Cache (BFCache) is not supported.** | ||
| By default, Playwright disables the Back/Forward Cache across all browsers. Even if explicitly enabled, Playwright's internal state relies on network-level navigation events. Because BFCache restores unfreeze the DOM without firing these events, using `page.goBack()` or `page.goForward()` to trigger a BFCache restore will result in timeouts and a desynchronized `Page` state. | ||
| ::: |
There was a problem hiding this comment.
i think you need to add this to packages/playwright-client/types/types.d.ts (and potentially also packages/playwright-core/types/types.d.ts too)
There was a problem hiding this comment.
Sure, thanks for pointing that out. I ran npm run watch and these were auto generated from the docs.
I have pushed those changes as well. Thanks for your time.
Test results for "tests 1"1 failed 4 flaky50206 passed, 1190 skipped Merge workflow run. |
Test results for "MCP"7760 passed, 1249 skipped Merge workflow run. |
What does this PR do?
This PR adds a brief warning to the Pages guide (
docs/pages.md) and the API reference forpage.goBack()/page.goForward()regarding the Back/Forward Cache (BFCache). It clarifies two things:Why is this needed?
I recently spent quite a bit of time going down a rabbit hole trying to write an E2E test for a BFCache bug I was fixing in an open-source project.
First, I struggled to figure out why the cache wasn't triggering at all (before realizing it was disabled by default in Playwright). Then, once I managed to trigger it, I couldn't figure out why
page.goBack()was consistently timing out or leaving the page in a desynchronized state.I eventually realized that because BFCache restores unfreeze the DOM without firing standard network-level navigation events (like
commitorload), Playwright's internalPagelifecycle tracking gets completely bypassed. (I documented my deep-dive into this limitation in this comment on my Forgejo PR, which ultimately led to me dropping the E2E test entirely).I thought adding a small note to the documentation might save other developers the hours of debugging I went through when trying to test this specific browser feature!
Feedback requested
I want to defer to the maintainers on this, if you feel there is a better way to phrase this, a better place to put it (e.g., only in the API docs vs the guides), or if you feel this is too much of an edge case to include in the core documentation at all, please let me know.
I am completely open to making adjustments or closing the PR if it doesn't align with the documentation goals. Thanks for taking a look!