Wp-calypso: Gutenberg Editor: WordPress.com Editor Fails to Load in Safari 12.1.x [1]

[pauljacobson]

Steps to reproduce

1. Starting in the WordPress.com dashboard, click on Site > Posts > Add New Post
2. The WordPress.com Editor fails to load when using Safari 12.1.x

What I expected

The WordPress.com Editor would open in Safari as with other browsers. I tried disabling cross-site tracking protection, here:

_Screenshot direct link:_ https://cld.wthms.co/FAgWAk

This didn't affect the result.

What happened instead

The block editor failed to load at all. Instead, I saw a blank screen, like this:

Screenshot direct link: https://cld.wthms.co/gFJpsN

Browser / OS version

Safari 12.1 running on macOS 10.14.4. A user who reported this issue is using Safari 12.1.1. Same result.

Context / Source

This is based on a report from a user in 2038016-zen.

[pauljacobson]

I have another site with an issue that may be related to this. This time, the WordPress.com Editor fails to load in Chrome 74 on macOS 10.14.5 (and 10.14.4). The editor looks like it's loading, and then fails with this screen:

I don't have a problem opening pages in the editor using Firefox, though.

The user is able to open posts and pages in the editor in WP Admin, though.

Reference: 2047317-zen

[pauljacobson]

This issue may be related to #32120

[desnum]

A user in #2053985-zen has this issue on:
Device: iPad Pro
Operating system: iOS 12.3.1
Tried: WordPress app and Safari browser

Update (pauljacobson): Here's a screenshot for this report:

[pauljacobson]

I have another instance of a user not being able to use the WordPress Editor to edit posts/pages in Safari in 13123792-hc.

macOS: 10.14.5
Safari: 12.1.1

The issue seems to be intermittent. The user reported that they were able to edit a post or page during the chat.

[lancewillett]

Removing the High priority label as the issue is intermittent. The editor UX team will take a look as part of their next maintenance sprint, see https://github.com/orgs/Automattic/projects/34

[gwwar]

Let's timebox to 1 day for additional investigation on steps to reproduce. If we're unable to reproduce, don't close the issue out unless reporters note that this is resolved.

[adamcapriola]

I have another instance of this to report from 2015533-zen

MacOS: 10.14.5
Safari: 12.1.1

[aamills]

Another report 13249742-hc
Follow up to user here 2088625-zen

MacOS: 10.14.1
Safari: 12.1.1

[davidmytton]

Removing the High priority label as the issue is intermittent.

For me this is not intermittent - it doesn't ever work on Safari.

[tijosh]

Apparently another report in #13187329-hc
Followup in #2104961-zen

[mmtr]

I spent some time on this today and it seems the problem is only present on Atomic sites. I updated the issue summary with more accurate steps to reproduce.

For some reason, Safari is not able to keep the user logged in on the WP Admin context when loading the iframed WP Admin block editor.

According to the work done in https://github.com/Automattic/jetpack/pull/12215, since Atomic sites have SSO enabled, Calypso should take care of the authentication but probably Safari is preventing Calypso from sharing auth cookies with WP Admin.

[mmtr]

Actually, disregard my previous comment. Just realized that I was testing with an Atomic site in which I manually disabled the SSO module. After enabling it, I cannot reproduce the issue on my test site. Will dig further.

[mmtr]

Tested some of my Atomic test sites (both using my user and SSP'ed as other test users I have) and didn't have luck trying to reproduce the issue.

I also checked several of the affected sites reported on this issue (while SSP'ed) and yet didn't have any luck identifying reliable steps to reproduce (the block editor loaded fine in all the scenarios).

Will move this issue again to our backlog and let's see if we receive more reports.

[khristiansnyder]

Another report: 9194688-hc
Safari 12.1 on Mac OS X 10.14.5

Disabling cross-site tracking lets the editor load properly in Safari. The editor would not open in Chrome either and they got the same redirect error as reported above: https://github.com/Automattic/wp-calypso/issues/33142#issuecomment-494704049

[guicmazeredo]

Another report:
13477182-hc

[davidmytton]

Disabling cross-site tracking lets the editor load properly in Safari.

This has no effect for me - still doesn't load.

[aamills]

Another report 13492497-hc
Follow up to user here 2137444-zen

MacOS: 10.13.6
Safari: 12.1.1

[kosiew]

Ticket: 2140651-zen
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15

[tijosh]

Another report in #13287566-hc

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15

User said no follow up needed

[noahtallen]

I was able to reproduce in Safari 12.1.x immediately when trying to create a new page on my Atomic test site. Unfortunately, I'm not seeing any console errors. I then turned "Prevent cross site tracking" off, force reloaded, and no longer got the issue. Even turning that back on, I was unable to reproduce. Since I haven't used Safari for wordpress.com previously, I thought it may be a caching thing. But I also can't reproduce it in a private Safari window.

[glendaviesnz]

I think @mmtr was on the right track with the login side of it. Looks like in some circumstances Safari gets stuck in an endless login loop between wordpress.com and the domain of the Atomic site.

It looks like it might be cookie related as I initially replicated it, but then flicked "Prevent cross site tracking" off and it worked fine, even when turning this setting back on, but if I removed all site data and cookies the issue came back again. Will try and work out what is causing this login loop.

[glendaviesnz]

Some extra detail:

With an Atomic site with custom domain the block editor parent page domain is wordpress.com, but the editor iframe domain is atomicsite-custom-domain.com. With "Prevent cross site tracking" enabled no cookie is set for atomicsite-custom-domain.com and the editor iframe gets stuck in the above mentioned login loop.

If "Prevent cross site tracking" is disabled a cookie is set for atomicsite-custom-domain.com and the editor iframe loads successfully.

Enabling "Prevent cross site tracking" and clearing the cookies/data for atomicsite-custom-domain.com brings the issue back again.

So having an Atomic site with a custom domain is probably they other key to replicating this issue. This is a well know issue with Safari and caused by its default prevention of 3rd party cookies, eg. an iFrame on a different domain trying to set a cookie.

[glendaviesnz]

A potential solution for this is something like:

• Having a script in the iFrame that detects if 3rd party cookies are enabled - needs to try setting and reading a cookie for this domain
• If they are enabled proceed as normal
• If they are not enabled break out of the parent frame and redirect to custom domain to auth and set cookie
• redirect back to the iFramed editor now that auth cookie for custom domain is in place

[jsnajdr]

Safari's tracking prevention prevents the Jetpack SSO login from finishing successfully. Here's the story of what's going on:

At the very beginning, I'm logged in to wordpress.com, which means that my browser has auth cookies (wordpress_sec) for the wordpress.com domain.

Then I go to my Atomic site's admin at

https://jarda.blog/wp-admin

But my browser doesn't have any auth cookies for that domain yet. So the server considers me logged out and redirects to:

https://jarda.blog/wp-login.php?redirect_to=https://jarda.blog/wp-admin

That's the Atomic site's login page. That page is Jetpack-enhanced, and tries to do Jetpack Single Sign-On. Therefore, it further redirects me, this time to wordpress.com login page:

https://wordpress.com/wp-login.php?action=jetpack_sso

I have auth cookies for the wordpress.com domain, so they are sent with this request. The server can verify it's me and redirects back to jarda.blog, telling it the good news:

https://jarda.blog/wp-login.php?action=jetpack_sso&result=success

The response to this request will contain Set-Cookie headers that set auth cookies for the jarda.blog domain. And the response will be a 302 Redirect to the page I requested at the beginning:

https://jarda.blog/wp-admin

But this time it's different: now I have the auth cookies for jarda.blog and the page will show the logged in view. The Jetpack SSO process succeeded!

Now let's do the same process inside an iframe on a page whole top-level URL is wordpress.com:

<b>Hi, I'm wordpress.com page</b>
<iframe src="https://jarda.blog/wp-admin" />

In this setup, browsers limit how the embedded jarda.blog page can access and set its cookies:

Block third-party cookies: If I'm not already logged into jarda.blog, I rely on the SSO process running inside the iframe being able to Set-Cookie for the jarda.blog domain. But browsers have been offering ability to block such cookies for many years. The option is called "Block third-party cookies" and one can find old articles from 2011 on how to enable it. Nothing new or specific to Safari ITP here.

Partition cookies: If I am already logged into jarda.blog, have the auth cookies for jarda.blog and don't need the Set-Cookie header command to be performed, I still haven't won yet. Safari ITP partitions the cookies by the top level document. It's also called "double-keying". It means that cookies for

jarda.blog

and

wordpress.com --embeds--> jarda.blog

are stored in two separate storage areas that don't see each other. Therefore, the embedded jarda.blog iframe doesn't see the auth cookies I got on previous visit to jarda.blog as top-level page.

Safari provides ability for the embedded iframe to access the top-level (aka first-party) cookies anyway. According to this article, it checks if I visited jarda.blog as a top-level page in the last 24 hours. And there is an API that the iframe can use to request access to the top-level cookies. But these rules change slightly with each Safari update and I don't know what's the latest state-of-the-art. @josephscott might know more as he's been fighting with Safari blocking our remote login for some time.

I don't know how exactly the Gutenframe login is being blocked, but here are some tips on what influences the seemingly intermittent bug:

• do I have auth cookies for jarda.blog?
• did I get them by visiting jarda.blog as a first party?
• did I ever visit jarda.blog? Did I visit it in the last 24 hours?

That all affects if I can see authenticated Gutenframe in Calypso at wordpress.com

Why does it break only for Atomic and Jetpack sites and not for Simple sites?
Because for simple site with custom domain jarda.blog, https://jarda.blog/wp-admin will redirect to https://jarda12345.wordpress.com/wp-admin first. Then there is no cross-domain activity, everything is withing the wordpress.com domain.

All simple sites have that canonical jarda12345.wordpress.com alias, but Jetpack and Atomic sites don't. Their only identifier is jarda.blog.

[glendaviesnz]

Safari's tracking prevention prevents the Jetpack SSO login from finishing successfully.

Thanks for all the extra detail @jsnajdr - I did discover so far that the only way to get this reliably working is to do a 1st party auth on jetpack sites before iFraming - the detail about this being time limited is helpful so we will try and account for that.

Apparently Safari ITP is a state machine so it can allow things to happen several times before clamping down it, so we also need to check that any solution doesn't just work one or two times, and then on the 3rd or 4th time Safari could change its mind.

[aleone89]

Another report here hc-14046665

The user cannot access it in any browser, and I can reproduce it. It is not the issue listed above

[ivan-ottinger]

Hey everyone. One of the user (#2266426-zen) says that clearing cookies fixes the problem but it returns after a period of time.

To make sure I understand correctly - does "prevent cross-site tracking" option have to be disabled?

Thank you.

[davidmytton]

Hey everyone. One of the user (#2266426-zen) says that clearing cookies fixes the problem but it returns after a period of time.

I am this user.

Following https://github.com/Automattic/wp-calypso/pull/34902 I retested this and the editor was unable to load. Safari is stuck in an infinite redirect loop. I cleared my cookies and then refreshed which required me to re-auth on wordpress.com. I did this, then clicked through to edit/credte the post again and it loaded without any problems. "prevent cross-site tracking" was enabled.

After about an hour, the edit post page stopped being able to save updates. Refreshing the page allowed me to reproduce the problem again with the infinite redirects as per the screenshot in https://github.com/Automattic/wp-calypso/issues/33142#issuecomment-514457449. I cleared my cookies again, re-auth'd and everything was fine for the rest of the day.

This morning I opened my laptop to the same problem - infinite 302 redirect between wordpress.com and my .blog domain. Disabling "prevent cross-site tracking" had no effect. Again, clearing cookies and re-auth'ing fixed the issue.

Sounds like this:

Apparently Safari ITP is a state machine so it can allow things to happen several times before clamping down it, so we also need to check that any solution doesn't just work one or two times, and then on the 3rd or 4th time Safari could change its mind.

which is referenced in https://github.com/Automattic/wp-calypso/pull/34902#issuecomment-516589279

[eduardozulian]

Pinging @mmtr and reopening this so we can check the above issue ˆ

[mmtr]

Thanks @dmytton for the feedback.

It sounds indeed like a problem on how long the third-party cookies are available. We'll have to rethink the current approach that workarounds that limitation (#34902), but unfortunately I cannot give an ETA at this time. We'll keep updated this issue with any progress.

In the meantime, you can use the WP Admin editor (accessed via <YOUR_DOT_BLOG_DOMAIN>.blog/wp-admin → Posts/Pages → Add New) which should load as expected in Safari.

[mmtr]

Given the existing issue is slightly different than the one originally reported (which should have been mitigated by #34902), I created a new issue to keep track of it separately: https://github.com/Automattic/wp-calypso/issues/35365

[chaitanyamsv]

Another report in 510120-hc

[nunyvega]

Another report in 15920712-hc
Safari Version 12.1.2 (12607.3.10)
OS Sierra

[chaitanyamsv]

4815020-hc