Implement `Page.goBack` and `Page.goForward`

[inancgumus]

What

Implement the goBack and goForward methods on Page.

Why

Using evaluate with navigational methods is racy:

await page.eval(() => window.history.back());
await page.eval(() => window.history.forward());

Using eval with code that causes navigation is racy because Chrome terminates the evaluate call after a navigation occurs, even if it executes the navigation code (e.g., history.back()). It results in seemingly obscure errors. That's an expected Chrome behavior because evaluate never lives across navigation.

For example, PR 5378 attempts to address this issue in one of our internal tests.

---

Other testing tools have safer goBack and goForward methods. These methods have a waitUntil option that allows waiting for the new page, avoiding possible race conditions.

How

Use the CDP's Page.getNavigationHistory and Page.navigateToHistoryEntry to move back and forward.

[NaMinhyeok]

Hello! I'd like to work on this issue. Here's my proposed approach:

Implementation Plan:

1. Use CDP's Page.getNavigationHistory() and Page.navigateToHistoryEntry()
2. Add GoBack() and GoForward() methods in page.go
3. Support waitUntil and timeout options (similar to Reload())
4. Map to JavaScript API in page_mapping.go

Questions:

• Does this approach align with the project's expectations?
• Should I follow the same pattern as other navigation methods (like Reload())?
• Any specific edge cases I should consider?

I've already prototyped this locally and can submit a PR if the approach looks good. Thanks!

[inancgumus]

Hi @NaMinhyeok, thanks for working on this issue. Please make sure to use the new Page.goBack in this test and remove the catch block (see the source code in that PR) to see if the test still fails. To detect if the test fails, you can either send a PR to run the test in our CI or run it locally in a CPU- and memory-restricted environment. The test is flaky and does not always fail when run on higher-grade machines.