Show warning messages in command log

[kuceb]

It would be useful to allow commands to print a warning instead of an error in the command log.

This would allow commands to alert the user something they have done may lead to unexpected behavior, such as pressing the {home} key while we cannot preform the default action of scrolling. Or calling a cy.wait after a cy.visit.

We could have:

• If there's a soft error during a command, allow a config value to turn it into a warning.
• If there's a warning during a command, add an icon to the command and allow it to be clicked and expanded
• Ability to add a new command log message / event for warnings/errors not linked directly to a command

[flotwig]

A bunch of warnings already exist in the driver, though they just dump to console.warn, where most users won't notice it:

cypress/packages/driver/src/cy/commands/xhr.coffee

Line 418 in 0cbd954

$utils.warnByPath("route.url_percentencoding_warning", { args: { decodedUrl }})

cypress/packages/driver/src/cy/commands/request.coffee

Line 100 in 0cbd954

$utils.warnByPath("request.failonstatus_deprecated_warning")

cypress/packages/driver/src/cy/commands/agents.coffee

Line 234 in 0cbd954

$utils.warnByPath("agents.deprecated_warning")

cypress/packages/driver/src/cypress/cookies.coffee

Lines 48 to 58 in 0cbd954

	log: (message, cookie, removed) ->
	return if not isDebugging
	m = if removed then "warn" else "info"
	args = [_.truncate(message, { length: 50 })]
	if isDebuggingVerbose
	args.push(cookie)
	console[m].apply(console, args)

cypress/packages/driver/src/cypress/cy.coffee

Lines 65 to 67 in 0cbd954

	msg = $utils.errMessageByPath("miscellaneous.mixing_promises_and_commands", title)
	$utils.warning(msg)

cypress/packages/driver/src/cypress/server.coffee

Lines 45 to 51 in 0cbd954

	warnOnStubDeprecation = (obj, type) ->
	if _.has(obj, "stub")
	$utils.warnByPath("server.stub_deprecated", { args: { type }})
	warnOnForce404Default = (obj) ->
	if obj.force404 is false
	$utils.warnByPath("server.force404_deprecated")

cypress/packages/driver/src/cypress/xml_http_request.coffee

Lines 127 to 137 in 0cbd954

	requestJSON: {
	get: ->
	$utils.warnByPath("xhr.requestjson_deprecated")
	@requestBody
	}
	responseJSON: {
	get: ->
	$utils.warnByPath("xhr.responsejson_deprecated")
	@responseBody
	}

[jennifer-shehane]

Yeah, we mostly use console.warn for deprecations currently.

I like this idea though. I feel like this is what most people would want for the 'uncaught:exception' messages we give. They do not want a test failure, but a warning may be nice.

Relevant to error improvements: #3762

[jennifer-shehane]

Played around with some of the design of this warning.

[jennifer-shehane]

Second iteration for design:

[kuceb]

@jennifer-shehane I like the yellow background with dark yellow/orange text 👍

[jennifer-shehane]

K, I need to rework the design to also work for inline commands - so the situation Ben originally described like

pressing the {home} key while we cannot preform the default action of scrolling

[jennifer-shehane]

• Establish pattern that draws the user's attention to something that functionally is fine - does not cause a failure, but that they should be aware of.
• Maybe have warn types - like deprecation, antipattern, misuse - even when it's not associated with a command?

Example: unnecessary assertion

cy.get('button').should('exist')

cy.get('button', { warn: false }).should('exist')

While functionally this won't break - the .should('exist') is unnecessary.

Example: antipattern?

cy.visit(...)
cy.route(...) // definition for a route that has already happened

Another cy.route() example warning: https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cy/commands/xhr.coffee#L419

We don't display route as a command in the command log, but when there's a warning, we should show it in there - similar to showing .then() when it throws.

cy.then(() => {
  throw new Error('foo')
})

You likely don't want to define the listener for the cy.route() after cy.visit() in this situation.

Example: limitations / unexpected behavior

In certain browsers, the home char sequence wouldn't really behave as you are expecting...

Like caniuse for mdn docs saying what does or doesn't work in browsers.

cy.get('input').type('foo{home}', { simulated: true })

cy.get('input').type('foo{home}', { simulated: true, warn: false })

Example: deprecation warnings

We do these in the console.warn now, but why not have it in the Command Log?

Example: async weirdness/mixing Promises and Cypress

Example: uncaught exceptions

Implementation:

Cypress.log({
  warning: ...
})

Should be expandable, but not expanded by default - unless outside of Interactive Mode.

Have ability to turn off warnings - maybe by type of warning.

• Possibly look at eslint / linting libraries for API inspiration (config verbiage).
• Also look at BlueBird config. http://bluebirdjs.com/docs/api/promise.config.html

Cypress.Warnings.defaults({
  warnOnMixedAsyncUsage: false,
  warnOnUncaughtExceptions: false,
})

Warning event (aka. like URL, XHR events...)

For uncaught exceptions - we do some complex things to associated the uncaught exception with a test / command - we should just create an uncaught exception event and highlight that also in red.

Side discussion As a breaking change - should switch logic to not fail by default on uncaught:exception - make them turn on failure for uncaught exception

Maybe add a code frame for the error events - honestly we should just design the UI of the warnings to be exactly like the 'failed' errors - with a 'docsUrl', 'code frame', 'stack trace', etc.

Dashboard

We could pin warnings to Dashboard results on the specs, "warnings tab?" - code frames - however Dashboard wants to design.

Could be multiple warnings per test - would require API changes.

[jennifer-shehane]

Another application for displaying a 'warning' instead of throwing. A person could screenshot an element that is 0 width and/or 0 height as described here: #5149

I wouldn't necessarily fail the test in this case but would want to show a warning that there will be no screenshot taken.