Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable animations for UI regression runs #5

Merged
merged 5 commits into from
Apr 21, 2022

Conversation

jdlrobson
Copy link
Member

See T306229
This will fix the dancing tabs issue.

See T306229
This will fix the dancing tabs issue.
src/engine-scripts/puppet/jsReady.js Outdated Show resolved Hide resolved
src/engine-scripts/puppet/jsReady.js Outdated Show resolved Hide resolved
default:
return true;
}
return mw.loader.getState( moduleName ) === 'ready';
Copy link
Contributor

@nicholasray nicholasray Apr 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a promise? e.g.

return mw.loader.using( moduleName )

As it stands, it doesn't look like its waiting for the module to finish loading. It looks like it's only checking its current state?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No using would have side effects.

I think I'm getting confused by the evaluate method. I think a setInterval that resolves when this is true is perhaps what I need?

My understanding is evaluate has to resolve to true to avoid timeouts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest looks fine to me. I'm curious where you heard that it needs to resolve to true though? The puppeteer docs have examples that don't strictly return true e.g. https://pptr.dev/#?product=Puppeteer&version=v13.6.0&show=api-pageevaluatepagefunction-args

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I was working on the scroll in the other patch, the scroll was synchronois and I was getting time outs if I didn't return something and didn't use an asynchronous function inside evaluate. I have found the documentation a little frustrating as it hasn't matched up with what I've been seeing

Comment on lines 27 to 35
// wait for animation frame or two.
// Wait until the next frame before resolving.
await new Promise( resolve => {
requestAnimationFrame( () => {
requestAnimationFrame( () => {
resolve();
} );
} );
} );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently throwing an error because it needs to go in a page.evaluate, but I'm also wondering if it's needed at this point? Can it be removed or have you had issues without it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even with the removal of animations we still use requestAnimationFrame for the resize to get it off the critical path so I think this is needed to be 100% sure. Moving it into the evaluate is obviously needed, that's my bad.

I'm wrapping up for the day so feel free to amend while I am out. If not I'll pick this up Monday.

@nicholasray nicholasray merged commit 423e8ea into wikimedia:main Apr 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants