Editor: Welcome Tour appears even if dismissed.

[worldomonation]

Quick summary

The welcome tour modal appears when launching the editor even if the state is marked as 'dismissed'.

Steps to reproduce

1. log in as gutenbergSimpleSiteUser. Login information is found in the encrypted configuration file.
2. click on Write on navbar.
3. wait until editor loads.

What you expected to happen

A new, blank editor is loaded.

What actually happened

Welcome Tour appears in the bottom left.

wp-editor__post-basic-flow-spec-start-new-post.mp4

Context

Automated end to end tests.

Browser

No response

Simple/Atomic

Simple

Other notes

LocalStorage (from Microsoft Edge):

WP_DATA_USER_147903583
{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"core/interface":{"enableItems":{"singleEnableItems":{"complementaryArea":{"core/edit-post":"edit-post/document"}},"multipleEnableItems":{}},"preferences":{"features":{"core/edit-post":{"welcomeGuide":false}}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","siteHasNeverPublishedPost":false}}

WP_LAUNCH
{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","siteHasNeverPublishedPost":false}}

Slack thread: p1636055367011200/1635542471.006000-slack-C029WGXE5T4
p1636045337071000/1635462959.039100-slack-CBTN58FTJ
p1636042344032100-slack-C01QG4Y91RR
p1635535550045200/1635462959.039100-slack-CBTN58FTJ
p1635462959039100-slack-CBTN58FTJ

Reproducibility

Intermittent

Severity

Some (< 50%)

Available workarounds?

Yes, easy to implement

Workaround details

For humans, the workaround is easy to implement.

• dismiss the tour.

For automated testing framework, this is a blocker as this blocks the retrieval of the iframed editor.

[worldomonation]

Yet another occurrence for TeamCity ID 6949795, with the same user.

[arthur791004]

I've logged in as gutenbergSimpleSiteUser and tested it, and I didn't see the “Welcome Tour” after the nux_status is marked as dismissed. Also, if we re-entered the editor, the “Welcome Tour” won't show anymore. How could I know which test case failed due to this issue? Maybe I can have another try via running e2e testing.

WP_DATA_USER_147903583
{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"core/interface":{"enableItems":{"singleEnableItems":{"complementaryArea":{"core/edit-post":"edit-post/document"}},"multipleEnableItems":{}},"preferences":{"features":{"core/edit-post":{"welcomeGuide":false}}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","siteHasNeverPublishedPost":false}}

Besides, the “Welcome Tour” will show according to your local storage as the value of showWelcomeGuide is true

[worldomonation]

I've logged in as gutenbergSimpleSiteUser and tested it, and I didn't see the “Welcome Tour” after the nux_status is marked as dismissed. Also, if we re-entered the editor, the “Welcome Tour” won't show anymore. How could I know which test case failed due to this issue? Maybe I can have another try via running e2e testing.

Typically, this issue is not reproducible by simply logging into the account using a browser. In other words, this issue is intermittent, but when it occurs it is quite readily reproducible in both CI and 'normal' desktop environments.

The Welcome Tour is shown despite the nux_status being set to dismissed (checked in the sandbox). Reproducibility of this issue is intermittent and unpredictable and I understand this isn't the ideal scenario.

However, the test statistics page for the spec specs/specs-playwright/wp-blocks__media-spec.ts: Blocks: Media (Upload) shows that this has failed 30 times out of the last 1000 runs, which is a pretty high intermittence rate, with the latest occurrence being today (November 11 @ 9:49pm UTC) in Run #7913.

Note that the step cited above is just one of the multiple in the entire e2e suite that attempts to Start new post as gutenbergSimpleSiteUser. Frequently, all of them fail at the same time due to the Welcome Tour problem, so the real impact of this odd issue is not limited to just one step in one test file.

WP_DATA_USER_147903583
{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"core/interface":{"enableItems":{"singleEnableItems":{"complementaryArea":{"core/edit-post":"edit-post/document"}},"multipleEnableItems":{}},"preferences":{"features":{"core/edit-post":{"welcomeGuide":false}}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","siteHasNeverPublishedPost":false}}

Besides, the “Welcome Tour” will show according to your local storage as the value of showWelcomeGuide is true

Perhaps this is the problem, but at the same time I recall tinkering with the value there to observe the behavior, and it is possible that the values I've copied into the description were from post-tinkering. In any case, this issue is intermittently reproducible in TeamCity and the values for LocalStorage are not set for e2e runs.

[arthur791004]

Maybe we should always run dismissWelcomeTourIfPresent before getEditorFrame inside the waitUntilLoaded function to ensure the Welcome Tour is dismissed 🤔

[worldomonation]

Maybe we should always run dismissWelcomeTourIfPresent before getEditorFrame inside the waitUntilLoaded function to ensure the Welcome Tour is dismissed 🤔

The failures are always at the step of obtaining the iframed editor itself, of which the Welcome Tour is a component.

If the iframed editor's handle cannot be obtained as expected, how will the tour be dismissed?

Edit: in my experiments I've tried using keyboard shortcuts to see if that works, to no luck. If you're aware of a shortcut that should dismiss this, please let me know.

[arthur791004]

Oh I'm sorry for my misunderstanding. But when I dive into test statistics page and #7913, the reason of failure is the timeout of obtaining the iframe editor or its title as you said. I don't understand why the Welcome Tour blocks the retrieval of the iframed editor.

Edit: in my experiments I've tried using keyboard shortcuts to see if that works, to no luck. If you're aware of a shortcut that should dismiss this, please let me know.

I just found we can click ESC twice to dismiss the Welcome Tour.

[worldomonation]

Edit: in my experiments I've tried using keyboard shortcuts to see if that works, to no luck. If you're aware of a shortcut that should dismiss this, please let me know.

I just found we can click ESC twice to dismiss the Welcome Tour.

Thanks, I will see if I can try doing that to work around the issue.

[worldomonation]

It looks like in order to dismiss this using ESC key, one would have to click on and highlight the Welcome Tour.

Since the issue is with the Welcome Tour likely blocking the locating and retrieval of the iframed editor in the first place, this isn't a feasible option. I'll have to think of anther potential workaround.

[worldomonation]

This issue has also been observed on I18N user as well, most often immediately changing the UI language.

[worldomonation]

Reproduced again on gutenbergSimpleSiteUser again.

LocalStorage:

{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"core/interface":{"enableItems":{"singleEnableItems":{"complementaryArea":{"core/edit-post":"edit-post/document"}},"multipleEnableItems":{}},"preferences":{"features":{"core/edit-post":{"welcomeGuide":false}}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","shouldShowFirstPostPublishedModal":false}}

{"core/nux":{"preferences":{"areTipsEnabled":false,"dismissedTips":{}}},"automattic/wpcom-welcome-guide":{"welcomeGuideManuallyOpened":true,"showWelcomeGuide":true,"welcomeGuideVariant":"tour","shouldShowFirstPostPublishedModal":false}}

[worldomonation]

The Welcome Tour seems to be disobeying the results of nux?_envelope=1 request.

In Playwright, I intercept and modify the request to nux?_envelope=1 such that it would return the following payload:

			route.fulfill( {
				status: 200,
				headers: { Allow: 'GET, POST, PUT, PATCH' },
				body: JSON.stringify( { show_welcome_guide: false } ),
			} );

However, this still results in the Welcome Tour showing.

The LocalStorage values show that Welcome Tour is set to true, despite the tour having been dismissed repeatedly by the user.

[WunderBart]

Running some suites in parallel locally, I've noticed that the Welcome Tour pops up every time the same site is being tested against concurrently. When running suites synchronously 1 by 1, the popup never came up. I haven't dug any deeper, but maybe it rings a bell @worldomonation @arthur791004?

[worldomonation]

@WunderBart I've only ever run my end-to-end tests synchronously (one spec file, in order) but without the --runInBand flag.

While we're on this topic, I had to come up with an alternative way to dismiss this pesky modal because the page.on construct to inspect every network request would end up causing issues in a small number of cases as things currently stand. This would worsen to causing issues 100% of the time as I found out while migrating the Post Privacy WPCOM spec to use Playwright.

I have a WIP PR that switches from page.on to page.waitForResponse and it seems to work this time. I'll give you a heads up when the PR is ready.

[worldomonation]

Frankly, this would be much easier if the show_welcome_guide value was actually respected but it doesn't seem to be the case at all, sadly.

[WunderBart]

@WunderBart I've only ever run my end-to-end tests synchronously (one spec file, in order) but without the --runInBand flag.

Just noting that even in this case, the site still might be "in use" by the CI from the same account, which means that the concurrent requests are still possible.

[supernovia]

Thanks for your work on this folks! We may have another case here:
https://wordpress.com/forums/topic/stop-welcome-to-wordpress-popup/

[csonnek]

Another report in https://wordpress.com/forums/topic/new-welcome-popup/

[jamiepalatnik]

Adding reports for follow-up from this related closed issue: #63765

• 5228082-zd-woothemes
• 17541658-hc
• 35740447-hc

[JessixBlade]

Another case here related to this error:

• 35918531-hc
• 5330802-zen (follow-up ticket)

[metabreakr]

• 5324827-zen

[inaikem]

@alshakero 👋 We're seeing a recent uptick of reports on this issue. Is there anything we can do to help get this escalated for more eyes-on and a fix? Thanks!

[inaikem]

• 33192589-hc (Initial chat)
• 5335731-zd-woothemes (follow-up ticket)

[paxblueribbon]

Reported in

35979867 - hc
5347868 - zen (followup)

[inaikem]

@cometgrrl 👋 Would it be possible for you to help nudge this along?

[cometgrrl]

@Automattic/vertex Can you take a look at this?

Anecdotally, I see the welcome tour more often than I should. I started taking screenshots to keep track, and I saw it on June 20th, and again on July 1st. Both on my team P2, same browser/computer/etc.

[heavyweight]

I'm investigating this issue.
I'm able to reproduce this consistently in 2 scenarios:

Scenario 1

• Go to the site editor and dismiss the welcome modal
• Reload the page
• The welcome modal will appear again

Scenario 2

• Go to the site editor and dismiss the welcome modal
• In the navigation menu go to post or pages
• Click to edit a post or page
• The welcome modal will appear again

From what I see this is a front-end issue.
In apps/editing-toolkit/editing-toolkit-plugin/wpcom-block-editor-nux/src/disable-core-nux.js we are subscribing to the store and the feature toggling select( 'core/edit-post' )?.isFeatureActive( 'welcomeGuide' ).
This is to detect when a user has clicked on the menu item Welcome Guide in the options menu.
This code opens the welcome modal with the option openedManually.
The issue is that this code is triggered on load instead of only getting triggered on menu item click.

[vajrasar]

Since the follow-ups were not a lot - I've reached the affected users manually. 👍

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 5228082-zen
• 5330802-zen
• 5324827-zen
• 5335731-zen
• 5491132-zen
• 5491136-zen

[vajrasar]

Since the follow-ups were not a lot - I've reached the affected users manually. 👍

Replied to more here:

5491132-zen
5491136-zen