Improve how config changes are handled

[chrisbreiding]

Currently, when cypress.json file is changed, we re-open the project and close the browser if it is currently open and running a spec. We do this because a config option like modifyObstructiveCode or chromeWebSecurity could have changed, which requires restarting the project and/or browser. The downside is that the currently running spec is 'lost' and the user has to manually re-select it to run their tests again.

When the plugins file is changed, we reload the plugins file and it automatically takes effect without re-opening the project or closing the browser. This is arguably wrong because the user could have changed options that affect the project or the browser. New events coming in 4.0 (run:start, spec:start, etc) will also necessitate the need to 'restart' the run (re-open the project). It's also an issue because it's not clear to the user that anything has happened when they change their plugins file, so they might think they need to completely quit and re-open Cypress for their changes to take effect.

We should make this consistent and improve the user experience for both these cases by doing the following:

• On cypress.json/plugins file updates, notify user in the browser that changes have occurred, noting where they occurred (cypress.json, plugins file, etc). These changes will not be loaded yet.
• In that notification, give the user a button with the option to restart the browser and project. It will re-open the browser with the current spec.

---

Tasks:

• Research/design
• Add change UI to Desktop GUI
• Add change UI to reporter
• Reload specs on config change events
• Review tests, make sure they're comprehensive

[lilaconlee]

First pass at design:

Some considerations:

• Should users be able to dismiss warning? (I think no)
• Is it clear what change prompted this dialogue? (I don't think so, would be up for including the name of the changed file and making the warning a bit more substantial.)

[brian-mann]

This is a great first start!

1. I don't believe dismissal is necessary either
2. It's definitely not clear, and I would like to provide to the user which file changed. It'll need to be intelligently truncated though - and ideally you could click the file and open it up in your IDE via the same mechanisms we've discussed recently. You might be able to get away with a message like:

The file: `my-app/cypress.json` was changed.
       [Reload to see changes]

3. We could potentially use like a notification or edit icon to help visually indicate this kind of notification in the top/left hand corner of the banner.
4. I think the light yellow has the wrong "feel" to it. Like it's trying to tell us something isn't quite right or there's a warning. Perhaps there's a light blue to provide a subtle hint/reassurance that reloading is what you want to do.
5. We could utilize a global shortcut like CMD+SHIFT+R and even put it in the reload link/button as text, which will help train users to understand they can reload without using their mouse. We can either do this directly using key bindings in the browser, or we could possibly utilize Electron global handlers. We could also intelligently only bind shortcuts when this notification is present.
6. I'm not sure about the placement of the notification being in the application under test area. It may be better to insert the message at the bottom of the specs, or alternatively... we could insert the message directly ABOVE the tests, but below the nav... which would push the tests down and prevent the message from floating on top of anything.
7. I do like the idea of adding "toast-like" alert notifications that disappear after a second or so. We could potentially repurpose your design and use it for things like indicating to you that your spec file was recently changed. EDIT: nevermind, there's probably a better and less obtrusive way to indicate recent changes to the spec.

[brian-mann]

@chrisbreiding and @jennifer-shehane and @bkucera and @flotwig thoughts?

[jennifer-shehane]

• I like the yellow color.
• It's not clear why you need to reload. It should say something like, "We noticed changes from your cypress.json file that may require you restart the browser."
• Is it 'restart' or 'reload'?

[lilaconlee]

Going to rework the design to get the file path in there and move around the browser warning placements. Some quick things before updating:

• I think the yellow works well to draw attention to something that requires action, we use the blue for the "Update your version" banner which seems kinda optional.
• I was using the "reload" wording that VS Code uses with extensions, but I've been waffling. I'll take a look at some apps with similar functions and see what they use.
• Chris mentioned IRL that we might want to use the UI blocking that he's added to 4.0 so that folks don't keep trying to run tests with the old config. I think we should not do that and let people continue to test with the old config if that's what they really want, but I can definitely see the argument against it.

[lilaconlee]

Second pass, also totally down to update the message to be something more friendly like "You should restart.."

[brian-mann]

The wording doesn't make sense now as it's basically telling me to go make changes in the file, but that's what I just did.

This file was changed: `/foo/bar/baz.js`
          Restart Cypress

I like the placement of the message in the desktop gui - but for the test runner, i don't think it should extend into the AUT area. I would see what it looks like isolating it to only be above the tests. Like displacing the same width as the tests currently do.

[lilaconlee]

Think we've got to direct folks to actually click the restart button, maybe something like this?

[flotwig]

I feel like the user knows that they've made changes, so we just need to gently remind them that their changes will not be applied until they restart. Some phrasing like: "cypress.json has been modified since starting Cypress. Changes will not take effect until you restart Cypress."

Looks good in the reporter pane!