Command Timeout Progress Bar

[panzarino]

• Closes Command Timeout Indicator [TTR-36] #7642

User facing changelog

Adds an animated progress bar indicating how close the running command is to timing out

Additional details

In order to implement these changes, two new fields were added to every command log object: timeout and wallClockStartedAt. These two fields are needed in order to know what the timeout is for a specific command (each command has different defaults and the ability to change the timeout through options), as well as how long the command has been running for when the progress bar is first displayed (displayed at different times based on number of tests in the file and arbitrary user clicks).

How has the user experience changed?

Here is an example of the progress bar when a command times out:

PR Tasks

• Have tests been added/updated?
• Has the original issue been tagged with a release in ZenHub?
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?
• Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

7584 • 0 • 119 • 0

---

Run details

Project	cypress
Status	Passed
Commit	b107537
Started	Jun 16, 2020 3:41 PM
Ended	Jun 16, 2020 3:48 PM
Duration	06:52 💡
OS	Linux Debian - 10.1
Browser	Multiple

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[JessicaSachs]

Threading options.timeout throughout the flow seems okay, but I’d like someone else to comment on this.

The UI code could be a bit cleaner and I left suggestions. The one I really care about is isolating the logic in the template into some sort of function or component. The Date stuff is a nitpick and just a suggestion to clean up the code and let you know there’s a diff way to spell it.

[jennifer-shehane]

This is really cool btw when you use it. 😄

1. So, it creates this 'jitter' effect due to the height of the command being 2px higher and then settling into the natural height of 2px less.

   Typically you'd want to negate this by always having the height of the command consistent whether there's a progress bar or not.

   

2. The animations still play when using .debug(). Not sure how we want to handle this.

   

3. I don't think progress bars are meant to be logged for just standard XHR requests / events that are not actual commands from Cypress. There is no 'timeout' for these completing, they respond when they respond.

   

4. This is what I meant when speaking of perf the other day. Some of the team said 'there will only be one progress bar at a time', but if you do something like the example below Performance issues of the Runner when using Cypress commands on many DOM elements at once #6967, it gets overwhelmed drawing 200+ wrap/invokes/asserts in the Command Log, all with progress bars.

   There is a perf problem in general, so this PR doesn't introduce that!

   With this PR, the example seems to be spending ~4sec more rendering though. And issuing a big warning about layout shift. (Perhaps because we're adding the element in with height and removing it - requiring layout to be recalculated).

   I'd probably like someone else to verify though because I'm not that great with the performance tools.

   it('perf', () => {
     cy.visit('https://entertainment.cathaypacific.com/catalog?template=movie&parent=Movies')
     cy.get('.carouselImage > poster-image > figure > picture > source', { timeout: 40000 }).each(source => {
       cy.wrap(source)
         .invoke('attr', 'srcset')
         .should('contain', 'http')
     })
   })

   

   4.8.0

   

   This PR

   

[panzarino]

@jennifer-shehane I was able to fix a majority of the issues described here.

As far as the debugging issue goes, the only way that I think this could be fixed is if there is some state that indicates that the tests have been opened in the debugger. Perhaps there could be an additional variable added to appState that indicates if the debugger is open, and that can be used to pause the animation.

The debugger gif you posted also revealed another small issue, that the progress bar would go back to full when complete, which has been fixed.

Fixed jitter effect:

Removed error where XHR requests would default to default command timeout:

Performance improvements:

Current develop branch:

These changes:

[JessicaSachs]

I validated that the jitter is fixed.

Another issue: on failed tests the spinner fails to stop spinning. You can trigger a failed test by hitting the "Stop" icon during a get command

I don't believe we need to pause the spinner when the debugger state is active.

[panzarino]

@JessicaSachs That issue is actually present on develop and I think its been like that for a while now. I feel like it warrants its own issue and fixing it is outside the scope of this PR.

[panzarino]

Note: assertion timeout is not synced with command timeout, must fix before merge

[JessicaSachs]

Once the timeout issue you mentioned is fixed, this looks good to me

[panzarino]

I have removed the progress bars under each assertion so that there can just be one progress bar that is synchronized around the whole command.

@bkucera and I decided that this progress bar should be displayed underneath the last assertion, but I was unable to find a way to accomplish this without a significant performance reduction. Therefore, the progress bar will be displayed underneath the top-level command as such:

This is probably not the ideal solution, but I am unable to think of any better viable solution.

[JessicaSachs]

Pulled it and ran it. Looks good to me.

[jennifer-shehane]

LGTM. I've rerun this firefox failing test a lot now and it keeps failing, so not sure there's something to investigate there.