next.js

ad65b1bd - test(app-basepath): increase waitForElementByCss timeout for hard-nav test (#91920)

test(app-basepath): increase waitForElementByCss timeout for hard-nav test (#91920) ### What? Increase the `waitForElementByCss('#page-2', ...)` timeout in the `app dir - basepath › should successfully hard navigate from pages -> app` test from the default 10 s to 30 s. ### Why? [Datadog test runs](https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.source.file%3Atest%2Fe2e%2Fapp-dir%2Fapp-basepath%2Findex.test.ts%20%40test.name%3A%22app%20dir%20-%20basepath%20should%20successfully%20hard%20navigate%20from%20pages%20-%3E%20app%22&agg_m=count&agg_m_source=base&agg_t=count&cols=%40test.status%2Ctimestamp%2C%40duration%2C%40test.type%2C%40test.is_known_flaky%2C%40test.name&currentTab=overview&eventStack=&fromUser=false&index=citest&start=1773951667400&end=1774556467400&paused=false) The test navigates from a Pages Router page (`/base/pages-path`) to an App Router page (`/base/another`) via a hard (non-client-side) navigation. In dev mode, the destination App Router page is compiled on demand the first time it is visited. That compilation can take longer than the default 10 s `waitForElementByCss` timeout, causing the test to fail spuriously with: ``` page.waitForSelector: Timeout 10000ms exceeded ``` ### How? Pass `30000` (30 s) as the second argument to `waitForElementByCss`. This matches the pattern used elsewhere in the test suite for dev-mode tests that are subject to on-demand compilation latency. No runtime code changes are needed — this is purely a test-side fix. Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>