Cherry-picked updated JS unit test cases commits from #7375 as new Gutenberg package updates are available and old ones are not merged yet.

Also see: #7375 (comment)

Plugin builds for cdbc29e are ready 🛎️!

• Download development build
• Download production build

I'm getting E2E errors repeatedly with this:

Run npm run test:e2e:ci

> amp-wp@ test:e2e:ci /home/runner/work/amp-wp/amp-wp
> cross-env WP_BASE_URL=http://localhost:[8](https://github.com/ampproject/amp-wp/actions/runs/3885317753/jobs/6633374780#step:11:9)8[9](https://github.com/ampproject/amp-wp/actions/runs/3885317753/jobs/6633374780#step:11:10)0 wp-scripts test-e2e --config=tests/e2e/jest-ci.config.js --runInBand


Chromium (982053) downloaded to /home/runner/work/amp-wp/amp-wp/node_modules/puppeteer-core/.local-chromium/linux-982053
........................
  ● Current active theme is reader theme and user is nontechnical › switches to transitional mode and shows a notice if the user chooses the active theme

    TimeoutError: Element p (text: "/transitional mode/i") not found

      waiting for function failed: timeout 500ms exceeded

.......

Sorry for creating merge conflicts by merging other dependency updates.

I'm getting E2E errors repeatedly with this

Yes, I am addressing the problem, and it can be duplicated. The problem arises when a non-technical user selects the reader theme, which is the same as the current theme, and switches to transitional mode. In this case, we display the following message to the user on the done page:

It's not functioning as planned after the upgrade to React18. My best opinion is that the state loss and/or certain useEffect bugs along the process are to blame. I also faced a bug due to useEffect which is fixed in d8028c7. (Also, see this comment on React18 changes page. )

Steps to reproduce the issue:

Switch to update/gutenberg-v14.9.0-packages branch > Build JS files > Go to onboarding wizard > Select user as non-technical on Technical Background > Select reader mode > Select same reader theme as current theme > and click next.

While moving forward to the done page you will notice a flicker in the UI and it causes the state loss(in my opinion). Due to the state loss, you will no longer be able to see the template mode change notice.

What ended up being the source of the problem with the E2E tests?

Actually, I see they're still failing?

@westonruter It's the same as mentioned in #7394 (comment) and I am investigating it.

As discussed, instead of upgrading React let's stay on React 17 for now.

• Downgrade this PR to React 17.x (including wordpress/* packages that depend on it).
• Configure Dependabot to only update minor versions of React v17. (This may not be relevant as we may rather need to pin the WordPress package dependencies.)
• Use our polyfills on all admin screens instead of deferring to WordPress's bundled version. In other words, the Polyfills service will no longer be Conditional

@westonruter Since several of the @wordpress/* packages now have React 18 as a peer dependency and some are upgrading as well, I believe we should temporarily block this PR. We will make the necessary adjustments and merge the changes once packages have stable peer deps.

Sounds good. Do we need to downgrade wordpress/* packages currently in develop?

And should we disable the GitHub Action entirely for now? No sense to have it keep running if it is going to always be closed.

Do we need to downgrade wordpress/* packages currently in develop?

Nope, all packages are already stable on develop.

And should we disable the GitHub Action entirely for now?

Yes, please.

Blocking this PR until the upstream(Gutenberg) package's peer dependencies are bumped to React 18(if any). Once all @wordpress/* packages become stable in terms of the peer dependencies version, we will amend the PR accordingly.

@westonruter JFI I have temporarily disabled the Gutenberg packages update workflow.

Since WordPress 6.2 is including React 18, I think this PR will need to be picked up again eventually.

Related: https://make.wordpress.org/core/2023/03/07/upgrading-to-react-18-and-common-pitfalls-of-concurrent-mode/

Of note:

We could undo the logic we had to prevent adding certain logic to the page if React 17 is not installed.

We could undo the logic we had to prevent adding certain logic to the page if React 17 is not installed.

I've filed this as #7489. In a subsequent release, we can consider upgrading to React 18, although this may require that we increase the minimum-supported version to WordPress 6.2.

Since many of the items were cherry-picked from this PR so closing this in favor of #7548.