Wp-calypso: Add message redirecting Safari users to wp-admin block editor

[davemart-in]

Description

41725 outlines that the Calypso block editor is not loading for Safari users. Here's what they are seeing:

This is likely due to the fact that since version 13.1 Safari has "Added cookie blocking for all cross-site resources by default."

Long-term

We are in the process of working with browsers to see if we can white-label 3rd party cookies on WP.com.

Short-term

We should add a message for Safari users who attempt to load the Calypso block editor which offers to redirect them to the wp-admin editor.

[davemart-in]

@olesyabrk would you mind spending some time thinking about this one? The Explorers are currently on Janitorial rotation and this just got flagged as an urgent issue.

[olesyabrk]

I have two options within our design system that could work here.

First is the Calypso error notice.

Second is the new Calypso (Gutenberg) modal.

The error notice is probably the easier to implement as a temp solution. I do need feedback on the wording @davemart-in.

[davemart-in]

Thanks for mocking these up. I'm trying to imagine myself as a Safari user having to go through this intermediary step every single time I go to add or edit a page/post. I think this could get pretty annoying. I wonder if we should just redirect these Safari users to the wp-admin block editor immediately and optionally show a notice there. That way the user doesn't have to click anything.

cc @amamujee and @simison for their thoughts since they brought this up initially.

[simison]

Redirecting straight to wp-admin when we notice issues with iframe would be wonderful. 👍

Do you feel it's important to write that they're in wp-admin after they land there or better just keep quiet and hope they don't get lost there? 😅 The editor should be full screen anyway and W logo hopefully brings them back to Calypso.

[davemart-in]

I think I'd vote to start there:

1. Auto-redirect safari browser users to wp-admin block editor
2. Hold off on showing a notice (but we may add one later if customers are getting confused)
3. Make sure the W link takes them back to where they came from

We'll also need to make sure Happiness is aware of the issue by pinging in the announcements channel.

@olesyabrk thoughts?

[olesyabrk]

@davemart-in and @simison let's go with that.

[pento]

43127 auto-redirects Safari users, but doesn't modify the W link: this is a little more complex, but is already in progress as part of FSE (#41703).

That said, I'm not entirely sure that #43127 is the correct fix. This issue appears to be happening with Jetpack/Atomic sites, not Simple sites. Additionally, HEs are reporting sporadic issues with the iframe in other browsers (pbg9X-eHh-p2), which makes me suspect there's something else going on.

It's a fairly confusing mess of interlinked issues: third party cookies (and possibly remote login), Jetpack SSO, and SSP all seem to be affected.

@katiebethbrown noted that she's been seeing sporadic issues for a while (_possibly_ as early as before the Jetpack 8.6 release). I've been looking in this direction a bit, seeing if there was anything relevant changed 1-2 weeks ago. #42183 was the change which most closely matched this problem, but I haven't been able to see a way that it could be the culprit.

I've also been digging through Jetpack (particularly focussing on SSO), but there don't appear to be any relevant changes.

Unfortunately, I haven't been able to come up with anything concrete for folks to dig further with, mostly a series of dead-ends. I can pick it up again tomorrow, but I'd appreciate some extra eyes on the problem, to at least check that I haven't made any obviously bad assumptions.

[glendaviesnz]

I case it helps here are 2 previous PRs I worked on last year to handle similar issues:

• https://github.com/Automattic/wp-calypso/pull/36977
• https://github.com/Automattic/wp-calypso/pull/34902

Given the redirect loop that is causing this issue I suspect the 34902 changes may be part of the issue as this attempts to redirect to wpadmin to authenticate if iframe load fails, and further tightening of Safari may have broken this approach.

[glendaviesnz]

Have looked into this further, and definitely looks like the same issue that https://github.com/Automattic/wp-calypso/pull/34902 attempted to fix.

The issue happens if the Atomic site is not authenticated, but the iframe thinks it is - you then end up with an endless auth redirect loop as the browser is not able to set cookies if the auth is taking place in 3rd party iframe.

Details here about how to replicate, along with a suggested solution of expiring the session storage value.

This was only ever fixed for Atomic sites, un-authed jetpack sites have never been able to load the editor in the iframe in Safari since the 3rd party cookie blocking was introduced - https://github.com/Automattic/wp-calypso/pull/35261 - so we probably also still need a nicer way to deal with Jetpack sites that can't iframe the editor