Domains: Display a notice when redirecting away from Google Workspace upgrade

[sirbrillig]

Changes proposed in this Pull Request

The Google Workspace upgrade page that's usually displayed between selecting a new domain and reaching checkout has a failsafe mechanism which will redirect back to the domains page if the cart does not contain a domain product. I believe that this might sometimes be triggered incorrectly (see the failing e2e test in #50723), but it's hard to know because the redirect is so fast and there's no context given to the user.

This PR adds a notice when the redirect occurs so that there's at least a reason given for ending up on a different page.

Before:

After:

Testing instructions

• Make sure your cart is empty.
• Visit the Google Workspace upgrade page directly at a URL like /domains/add/google.com/google-apps/example.com (the first domain name is the domain you're supposedly adding so it can be anything; the second domain name is your wp.com site).
• Verify that after the page loads you are redirected to the "Site Domains" page which lets you search for a domain.
• Verify that you see a notice message mentioning that there is no domain in your cart.

[matticbot]

Test live: https://calypso.live/?branch=add/notice-to-gsuite-upgrade-redirect

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~96 bytes added 📈 [gzipped])

name     parsed_size           gzip_size
domains       +240 B  (+0.0%)      +96 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[nbloomf]

I see a couple of issues, one probably less important than the other.

Less important: If I put a domain in the cart and then manually load the Workspace upgrade url using a different domain, the error message says "there is no domain in your cart" when this is not actually true. On the off chance that a user could see this message, maybe it could instead say something like "To add an email product for example.com, you must either already own it or have it in your shopping cart."

More important: Cobalt can verify this, and it appears to predate this PR, but I think the redirect logic may be too aggressive. This redirects if the domain is not in the cart, but I think email should still be purchasable if I already own the domain (and thus may not have it in the cart). E.g. the following ends in a confusing redirect:

1. Complete purchase for domain example.com
2. Manually load /domains/add/example.com/google-apps/mywpsubdomain.wordpress.com
3. Get redirected to domain search page with an error message.

[sirbrillig]

Less important: If I put a domain in the cart and then manually load the Workspace upgrade url using a different domain, the error message says "there is no domain in your cart" when this is not actually true. On the off chance that a user could see this message, maybe it could instead say something like "To add an email product for example.com, you must either already own it or have it in your shopping cart."

Good point. I've updated the text.

This redirects if the domain is not in the cart, but I think email should still be purchasable if I already own the domain (and thus may not have it in the cart)

I think this is handled by a different flow. This flow is AFAIK only used when coming from the "add domain" page (which means that in theory this error should never happen but the guard implies that it may).

[sirbrillig]

I think this is handled by a different flow. This flow is AFAIK only used when coming from the "add domain" page (which means that in theory this error should never happen but the guard implies that it may).

Also, even if this did happen, it's probably better to have an error message than to have no message.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/5568006

Thank you @sirbrillig for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.