Remove duplicate views: Fix Page Basic Flow E2E test

[mmtr]

See p1737384275008899-slack-C034JEXD1RD

Proposed Changes

Updates the logic to click on the "Add New Page" button for the Page Basic Flow E2E test since apparently it was broken when we started the "Remove duplicate views" experiment

Why are these changes being made?

Because there is a broken e2e test

Testing Instructions

Run this locally:

export TEST_ON_ATOMIC='true'        
export ATOMIC_VARIATION='ecomm-plan'  
export JETPACK_TARGET='wpcom-deployment'          
yarn workspace wp-e2e-tests build  
yarn workspace wp-e2e-tests test -- specs/editor/editor__page-basic-flow.ts

Make sure the E2E test passes

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-130342

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-130342&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-130342&env=a8c-for-agencies

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[anomiex]

Looks ok to me. 👍

[anomiex]

I wonder if we could improve the timeout situation by doing like this instead.

await this.page.waitForNavigation( { url: /post-new.php\?post_type=page/, timeout: 20 * 1000 } );
await locator.click( { timeout: 20 * 1000 } );

I think that way it won't start the timer for the click until after the page is navigated to, instead of starting both timers at the same time.

[mmtr]

waitForNavigation does not navigate to a different page, it only introduces a blocker until the URL changes. It's the click action what produces the navigation.

So if we wanted to have a sequence, it should be the other way around:

// Navigate to "Add New Page"
await locator.click( { timeout: 20 * 1000 } );
// Wait for "Add New Page" to be loaded
await this.page.waitForNavigation( { url: /post-new.php\?post_type=page/, timeout: 20 * 1000 } );

The two are intrinsically related, so I think it makes sense to group them in the same promise.

[anomiex]

TIL, thanks!