e2e tests - update site editor component waitForTemplateParts method.
#56441
Conversation
Addison-Stavlo
requested review from
scinos,
WunderBart and
a team
as code owners
matticbot
added
the
[Status] Needs Review
|
Link to Calypso live: https://calypso.live?image=registry.a8c.com/calypso/app:commit-6864aec5c5fc29aeebdc4044023c5dbe64b7cc94 |
|
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. |
There was a problem hiding this comment.
Hrm, actually, now it looks like i'm getting a failure in the wp-site-editor test!
[WPCOM] Site Editor (desktop) @parallel
✓ Can log in (16434ms)
✓ Can open site editor (547ms)
✓ Site editor opens (207ms)
1) Template loads
3 passing (48s)
1 failing
1) [WPCOM] Site Editor (desktop) @parallel
Template loads:
Error: TimeoutError: Waiting to be able to switch to frame
Wait timed out after 20109ms
at Proxy.<anonymous> (lib/driver-manager.js:97:14)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Proxy.waitUntilAbleToSwitchToFrame (lib/driver-helper.js:194:9)
at async SiteEditorComponent.runInCanvas (lib/components/site-editor-component.js:17:3)
at async SiteEditorComponent.waitForTemplateToLoad (lib/components/site-editor-component.js:37:3)
at async Context.<anonymous> (specs/specs-wpcom/wp-site-editor-spec.js:37:3)
|
Actually, both of these are failing on my machine on trunk... Hmm... I'm going to try to trigger this for this branch on TeamCity and see how it runs there! |
|
👋 @dpasque
They should fail on trunk as the fix here is necessary.
It looks like im getting this failure now too. It seems like an issue with the test site as I see the site editor is not actually loading there now (gray blank editor screen). Investigating... |
Oh, duh! 🤦 I clearly didn't get enough sleep last night. 🙃
That's what I was seeing too! |
|
Its interesting, I cannot repro with my own test sites. But loading up the e2e sites for the site editor (both edge and non-edge) seem to do this. |
Weird! Should we spin up a separate issue for this you think? I'm also good with this merging too! The code changes look fine and we can have the fixed tests then to validate this other issue once it's fixed! |
Yeah, il spin up an issue. I can find a couple of my own test sites that are like this as well (and others are fine! 😕 ). 😆 |
Addison-Stavlo
deleted the
fix/site-editor-component-wait-for-template-parts-method
branch
github-actions
bot
removed
the
[Status] Needs Review
|
created an issue for the gray screen bug here - #56512 |
Changes proposed in this Pull Request
Updates the
waitForTemplatePartsmethod to be more accurate to its purpose. Fixes testsspecs/specs-wpcom/wp-calypso-gutenberg-site-editor-tracking-spec.jsandspecs/specs-wpcom/wp-site-editor-spec.jsCurrently, this method waits for the following selector to not exist in the editor
.wp-block-template-part .components-spinner. However, it is possible (and has happened with recent theme updates) that other blocks inside a template part may have their own spinner components.Here, we update this to only be concerned with spinners that are direct children of the template part. As this is how gutenberg renders the template part loading state
wp-block-template-part > .components-spinner.We have also added another condition to ensure the template part is not in a warning state
.wp-block-template-part > .block-editor-warning. Previously, when template parts were not resolved the spinner component would be in place perpetually. With more recent Gutenberg updates, when the template part cannot be resolved it renders a warning component. Thus this extra condition now helps ensure that the template part is properly loaded.Testing instructions
specs/specs-wpcom/wp-site-editor-spec.jstest file and verify it no longer fails on the template part assertion.specs/specs-wpcom/wp-calypso-gutenberg-site-editor-tracking-spec.jsand verify it no longer fails in the first test.Related to #