-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
fix: electron slowness within cy origin #21445
fix: electron slowness within cy origin #21445
Conversation
Thanks for taking the time to open a PR!
|
@@ -94,12 +94,4 @@ | |||
transform-origin: 50% 0; | |||
width: 100%; | |||
} | |||
} | |||
|
|||
.spec-bridge-iframe { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these styles were still being injected, but it doesn't really make sense for the style to live here any longer, but inside the app
, package.
Not sure how you figured out the styling was the problem - why does the style of the spec bridge so heavily impact performance? Any theory? |
@@ -0,0 +1,20 @@ | |||
it('visits foobar.com and types foobar inside an input', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason this can't be a driver test instead of system test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in particular. Main reason I didn't add it to the driver
tests is the main test is really to test additional styles to the app
package and behavior. I originally started with a cy-in-cy
test inside the app
package, but had issues configuring the host, plus it only ran in chrome and regressions would likely be a lot more obvious in electron. So I just moved it to a system test 🤷 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer that this and the other ones be driver tests.
In general, it's better to use regular Cypress tests (driver tests, etc) if possible and reserve system tests for when it's not possible to write regular Cypress tests, like when the tests need specific project configuration, need dependencies the driver does not have, or when testing certain failures. It's much easier to iterate on driver tests as well as debug any failures, plus the results go to the Dashboard and utilize retries and config we already have set up for them.
It's alright if the tests cover more than driver behavior. A lot of the driver tests are true e2e tests. Since this issue is specific to cy.origin(), I'd say the driver is as appropriate a place as any for the tests.
expect(specBridgeIframe.offsetTop).to.equal(currentBody.offsetTop) | ||
expect(specBridgeIframe.offsetLeft).to.equal(currentBody.offsetLeft) | ||
expect(specBridgeIframe.clientWidth).to.equal(currentBody.clientWidth) | ||
expect(specBridgeIframe.clientHeight).to.equal(currentBody.clientHeight) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this PR is fixing a performance issue, but I believe the original reason the spec bridge needed to have the same dimensions as the AUT is for the sake of screenshots having the correct dimensions.
I wonder if there was a behavioral regression as well that this fixes, but it doesn't look like we have test coverage around screenshot dimensions for screenshots taken within cy.origin(), so it didn't result in a failing test. If so, I think asserting on the screenshot behavior would be a good idea. It would also be better since it would assert on the behavior instead of the implementation details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I am going to look into seeing if we can add in a few screenshot tests that assert on the behavior of the screensize within cy.origin
for a few different use cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unlikely there was a behavioral regression since the size of the frame was still correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a few system tests could hurt to verify the screenshot in case there are some weird layout issues that occur in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrisbreiding how is something like 70e3251? It's based on the system tests that currently exist for snapshotting to just verify the dimensions of clipped, element, and full page snapshots.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Those are exactly what I had in mind.
Like I said in my other comment, I think they should be moved into the driver's tests. They would fit in well in origin/commands/screenshot.spec.ts. You'll just need to copy over the check:screenshot:size
task or share it some manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Those are exactly what I had in mind.
Like I said in my other comment, I think they should be moved into the driver's tests. They would fit in well in origin/commands/screenshot.spec.ts. You'll just need to copy over the
check:screenshot:size
task or share it some manner.
@chrisbreiding I got everything moved over into the driver and now looks to be working properly.
@lmiller1990 I got lucky. @chrisbreiding brought up yesterday that maybe the performance was related to the iframe size. When I set the spec bridge iframe to have a I am unsure why this is happening. My guess is |
Co-authored-by: Chris Breiding <[email protected]>
…ots within cy.origin
…ypress-io/cypress into bugfix/fix-electron-slowness-cy-origin
Interesting... there are definitely a number of differences in electron and chrome, even if they are using the same internals, more or less, specifically with frames. Here's another one: #15932 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to see some regression tests added. Thanks for this. I wonder if we need a more aggressive comment explaining the CSS you added is perf-critical - right now it reads like "this is some style" not "this is critical for perf, don't mess with it".
@lmiller1990 I'll add a bit more explanation in the |
…ypress-io/cypress into bugfix/fix-electron-slowness-cy-origin
…fix/fix-electron-slowness-cy-origin
…ypress-io/cypress into bugfix/fix-electron-slowness-cy-origin
5d17f52
to
bffe6e7
Compare
bffe6e7
to
0fe394f
Compare
@lmiller1990 I added some more comments in e26ae8b |
Looks good to me. |
User facing changelog
Additional details
After merging
cy.origin
into the10.0-release
branch, it was noticed that certaincy.origin
tests were performing incredibly slow in electron. It turns out the root cause of this was the spec bridge iframe being beneath the Spec Runner / Reporter / AUT, which for some reason was causing electron to slow down drastically. In9.x
, the spec bridge overlays the Reporter / AUT due to how the UI layout is structured. That structured changed in10.x
, which made this problem visible. We were able to reproduce this issue in9.x
by attaching the spec bridge after thebody
element, instead of within it. To fix this in10.x
, we need to set the spec bridge to be within the viewport by settop
andleft
to0
. This is verified by a new system test added to make sure the spec bridge isn't shifted south of the AUT.CURRENT in
9.x
Spec Bridge overlaying AUT (no performance issue visible)9.x
Spec Bridge beneath AUT (performance issues present)10.x
THIS PR Spec Bridge overlaying AUT (no performance issue visible)CURRENT
10.x
Spec Bridge beneath AUT (performance issues present)How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?