Wp-calypso: Preview sometimes 404s (more often on Safari)

[AMcGrady]

Summary Update from @gwwar 10/22

Summarizing some comments below folks are still reporting that site previews sometimes fail in Calypso, with a higher success rate of this failing in Safari. Folks who are investigating, please do not close this issue if you have trouble reproducing. We have enough reports here to dig deeper into the issue. I suspect checking for race conditions, bad auth cases, or bad Calypso caches would be some leads to dig into first.

Steps to reproduce

1. Starting at URL: thecedarjournal.com
2. Open a Draft or Scheduled Post in Gutenberg
3. Try Previewing the page
4. See Page not found Error

What I expected

To see a preview of the post.

What happened instead

Page not found.

Browser / OS version

https://whatsmybrowser.org/b/QQNZ99U

User is hosted on WordPress.com and is using theme Booklet which is a retired theme. Error occurs in both Calypso and wp-admin.
This doesn't happen in Chrome or in either browser within the classic editor.

I was able to reproduce the issue while logged in as the user (SSP) but was unable to test on my own wp.com account as I don't have access to the Booklet theme.

Clearing cookies and cache did not help.

Re-raised in p58i-89x-p2

[nerdysandy]

Reported on 1710205-zen

[AtrumGeost]

Reported here 1751630-zen

[hannahswain]

Reported here: 1850115-zen

[kristarella]

I think this might be a duplicate of #29324, which may be related to https://github.com/WordPress/gutenberg/issues/13232

[GeoJunkie]

Reported in 9227951-hc. When I previewed a new post in their dashboard using Chrome, I saw a 404 briefly appear, then it refreshed and disappeared. It looks like Safari may not be following through on the refresh part.

[AtrumGeost]

Got another report here 4607264-hc. Not sure what to do about the duplicate that mentioned @kristarella 😅 — this one seems specific to Safari (?)

[kristarella]

@AtrumGeost I think they are all related and the issue is just worse in Safari because Safari has an über sticky cache
I've been trying to write up a unifying report for them, but for now we just need to keep tracking, and hope a developer is able to investigate too.

[joweber123]

Reported here: 1872673-zen

[joweber123]

Reported here: 1872683-zen

[Robertght]

Another one 1868632-zen

[codebykat]

The underlying implementation has changed since this was reported, and I am now unable to reproduce this issue. I tested by SSPing as the user in the initial report on both Firefox and Safari.

[darnelldibbles]

Issue reported again here:
https://twitter.com/mikecane/status/1130132419259060224

I was able to reproduce the issue:

Preview for the same post works in Chrome but not in Safari:

Chrome:

Safari:

[codebykat]

@darnelldibbles I just tested and preview is working for me in Safari. I started from wordpress.com/block-editor, created a new post, added a little content and immediately previewed it. Can you please share more details? Is this a WPCOM Simple Site, Atomic, or Jetpack? A new post or one that has been published already? Are there any errors in the browser console?

[codebykat]

Noting also that the issue reported on Twitter ("When previewing a post, there seems to be no way to scroll at all") is different from the one @darnelldibbles saw. In their case, I wonder if this is an unfamiliar browser issue -- Safari does not show a scrollbar by default, I think?

[tijosh]

Another report of this in #2254207-zen

User is on Chrome on Windows

I'm able to reproduce this in Chrome on the user's site when trying to Preview a post for the first time. After clicking "Close" and then "Preview" again, the preview appears.

[katiebethbrown]

User from #2254207-zen replied again. They have the same issue in Firefox on Windows. I can replicate in Firefox on Mac as well when SSP'd, which makes this case seem account specific rather than browser based.

Preview always loads a blank screen for existing posts (doesn't load on the second try for me).

The preview iframe contains blank HTML:

There are related console errors as well:

When I test a new post with just text I can preview, but get the 404 error on the first preview, and the correct preview loads on the second try.

[katiebethbrown]

I also found this issue - #33799 - which seems directly related.

[liviopv]

Another report in #14430653-hc.
Safari/Mojave

[tijosh]

Another report in #2421103-hc using Safari

[tijosh]

Another report in #15048184-hc using Safari

@codebykat seems like we keep getting reports of this. What would be needed to move ahead finding a fix?

Seems like we've made some progress on broken previews recently; possibly related? https://github.com/Automattic/wp-calypso/pull/35824

[eduardozulian]

Another report in 2381508-zen, using Chrome.

• I was able to reproduce the problem
• No blank screen
• The preview shows a Not found message.
• It's not regular. Sometimes we see the 404, somethings we actually see the post/page preview

As a workaround, for now, I recommended the user to:

1. Click on Preview
2. If they see the 404, click to Close the preview
3. Click on Preview again

[retnonindya]

Report here #15587183-hc.

I suggested the user clear browser cache and @eduardozulian's workaround (click Preview - close - reclick Preview again)

[joweber123]

Another report here #15576695-hc

[gwwar]

Related is https://github.com/Automattic/wp-calypso/issues/36837, though folks reporting this one will always 404.

Going to update the summary to reflect some of the more recent comments.

[gwwar]

Note also https://github.com/Automattic/wp-calypso/issues/33799 for reproduction hints.

[kriskorn]

Browser: https://whatsmybrowser.org/b/JPMFUJ5
Report: 16069836-hc

User gets a 404 on Windows 10 Pro on all draft post previews with MS Edge 18. This started on 18.10.2019 for them. I have tested an almost identical setup as them and could not reproduce on my end.

Console shows: HTTP404 - The server found no matches for the requested URI.

They cannot see a preview, when the URL ends like this - ?p=1586 - but they can see it when it ends like this - ?p=1586&preview=true

Browser's cache and cookies cleared. Turned off any Edge settings that could have possibly blocked the preview. No browser extensions or web security software. Firefox works for them.

[gwwar]

We have some better fallback behavior coming soon in https://github.com/Automattic/wp-calypso/pull/36841 and have closed out the two other known preview issues.

It's still worth digging into seeing if there's another major case we're missing with safari. ✅

[StefZarb]

Another report in 2484564-zen (Safari)

[katiebethbrown]

Reported in 16642376-hc (Safari)

[rachelwinspear]

Reported in Safari here: #2480860-zen

[marcuswisecaesar]

From the report here: #2480860-zen

The user followed these steps and still resulted in a 404 error.

*Please then Click on Preview of the draft blog post, if you do see the 404 error, you can click to Close the preview and then click on Preview again. *

[caimin-j]

Another confirmation in #2531638-zen.

[jordesign]

Another report in #16391714-hc

[aisajib]

We received another report from a Safari user who confirmed it was working on Chrome. Reference: #2563074-zen

[joweber123]

Another report here of a user with Safari. 2562442-zen

[josephscott]

Summary This behaves like a Safari ITP issue, but doesn't seem to be following the regular ITP flow

---

I've been looking at this to see if there is something from a Safari ITP angle that I can help with. I'm going to leave some notes here on what I've been able to observe so far.

1 - I have not been able to reproduce this with Chrome ( 79 or 80 )
2 - I have not been able to reproduce this with Firefox ( 71 )
3 - I am able to reproduce this with Safari ( Safari Tech Preview 97 )

With that as a baseline, I've been focusing on what Safari is doing. Because this is an iframe situation that crosses domains, it would fall into the realm of ITP. Here is what I'm doing to test ( all in Safari Tech Preview 97 ):

• Start watching the ITP log with log stream -info | grep ITPDebug in the terminal
• Make sure Prevent cross-site tracking option is enabled
• Clear all history
• Restart Safari Tech Preview
• Turn on Enable Intelligent Tracking Prevention Debug Mode
• Log in with test user
• Edit draft post on mapped domain
• Click Preview
• Iframe preview comes up with Not Found page

At this point I get to things that would normally point me towards ITP. First, getting the Not Found page instead of the regular post. Second, the admin bar at the top of the iframe only looks half logged in ( only My Site and Reader show up ).

The part that confuses me about is that there is nothing in the ITP debug log to indicate that any of the domains in use were flagged ( wordpress.com or the mapped domain for the test user ). At this the ITP debug log doesn't mention any domains, the only entries are:

0x28a437 Info 0x0 53510 0 com.apple.WebKit.Networking: (WebKit [com.apple.WebKit:ITPDebug] Done updating cookie blocking.

To try and narrow this down, I repeat the above steps with one change:

• Make sure Prevent cross-site tracking option is DISABLED

Instead of the Not Found page I get the expected preview of the post. So we know that it works if you turn off that option and start from the beginning.

One more combination I tried is the all of the original steps, then afterwards turns off Prevent cross-site tracking. Then:

• Close the preview iframe
• Click Preview
• I still get the Not Found page
• Close the preview iframe
• Click Preview
• Now the expected post preview shows up again

This too points to the one option controlling if the post preview works or not. And the ITP debug log still has no mention of flagging domains, just more of the Done updating cookie blocking entries.

To me it looks like there is some sort of baseline cross-site tracking prevention that is happening before ITP ever gets around flagging anything. The other possibility is that the ITP debug log is not telling the whole story. Either way, there is something going on under the hood of Safari that I am not seeing.

I'm going to reach out to @johnwilander on the WebKit team to see what we may be missing.

[josephscott]

After chatting with John he pointed out something that allowed this to work again for me. The key point in this particular flow is that you need to interact with the mapped domain directly before cookies would be allowed in iframe.

Using the first set of steps to reproduce in my previous comment, if the mapped domain is example.com then you would visit that as step zero.

Long term, this particular flow just isn't going work when run up against Safari ITP. It would need to be redesigned to work within the requirements of the storage access API. Right now we could do that by simply prompting inside the iframe, but that is only good for that iframe, on that page view.

We could expand it if the Preview button itself was within the iframe used to show the post preview, then at least the iframe would persist ( instead of coming and going for each preview ).

I think we could come up with other options as well, all of them are going to require re-thinking how the post preview flow works, in a significant way.

[GeoJunkie]

Encountered in mobile Safari in 17498480-hc

[lakellie]

Another report in 2595675-zen

[johnwilander]

Hi! John Wilander here, lead engineer behind Safari's ITP.

I just wanted to mention that you can always bring up enhancement requests with us on how ITP and the Storage Access API work. The easiest way is to file open source bugs at https://bugs.webkit.org with your use case. Just don't make suggestions that would regress tracking prevention or introduce some kind of whitelisting mechanism because we've received plenty of those and they are not options on the table.

So what could you suggest? Well, is there something that would make integration with the Storage Access API easier? Is there something in particular with current scoping or TTL of the Storage Access API that hinders you?

If you look back at our revisions to the Storage Access API, you might notice how we changed it so that storage access was maintained if the iframe navigated _same-site_. This was based on developer feedback where they explained how they wanted to re-render their iframe after getting cookie access with login status. That's a good example of a totally reasonable request that we were happy to deliver on.

Another example was the request to retain the user gesture if storage access was denied because it couldn't be granted. That way, a login window could be opened in the promise completion handler without requiring another user gesture to get past the popup blocker. Another very reasonable request.

Hope that helps!

[lakellie]

Another report in 2603690-zen and the user experienced the issue in both Safari and Chrome

[tbradsha]

17608516-hc (Safari 13)

[katiebethbrown]

17747626-hc

Safari 13.0 on Mac OS X 10.14.6

[jonnyruzek]

16307010-hc Safari 12.1 on Mac OS X 10.13.6

[dcoleonline]

2621421-zen Safari 13.0.4 MacOS 10.14.6

I believe I've found a workaround. Just visiting the domain in a new browser tab didn't work.

Here are the steps that worked for me:

1. Go to wp-admin
2. Click a post that you want to preview so that the editor opens
3. Click the preview button within the editor
4. A preview successfully opens in a new tab
5. Return to Calypso
6. Click on a post under My Site > Sites > Posts
7. From the Calypso editor, click the Preview button
8. The preview for that post and other posts will now work from the Calypso editor.

[StefZarb]

Another report in 2624369-zen with Safari 13.0.4 MacOS 10_15_2

[ccwalburn]

Another report in 5981664-hc with Safari.

I tried all 3 workarounds mentioned in this thread and none of them worked.

Previewing from the 3 dots next to the post (instead of clicking preview in the post) does work, though.

[SiobhyB]

We had another report in 18235240-hc, with the user using Safari. They've switched to the classic editor as a workaround, as they noted that that's their preference for now.

[thabotswana]

Another report in 2660913-zen with Safari 13

[GeoJunkie]

Reported in 12172041-hc

The WP Admin workaround worked (at least to view it, they're just going to use WP Admin for the preview). The user also noticed the links were different for the preview.

When I access the preview on WP Admin, it goes to:

https://{WPCOMDOMAIN}.wordpress.com/?p=355&preview=true

In Calypso the preview link is:

https://{CUSTOMDOMAIN}.com/?p=355&preview=true&_thumbnail_id=357

I get the same results trying to access the second link in Safari (even directly).

The use of the custom domain vs. the WPCOM domain may be part of the issue...

[sophiegyo]

I had a report of this:
18543046-hc

Safari version: version 13.0.3
Mac OS: 10.14.6

They're working primarily in wp-admin, and they reported that previewing drafts from the wp-admin posts overview (wp-admin/edit.php) works fine, but not while they're actually editing a post.

User also confirmed that the workaround mentioned above doesn't work for them.
They tested in Calypso and reported that the preview doesn't even load anything at all, let alone a 404.

They tested in Firefox on a different device and confirmed it's just fine in FF, so it's isolated to Safari, it seems.
I wasn't able to test myself at the moment.
We didn't try switching them to the classic editor at the moment, though it's another potential option.

[GeoJunkie]

Came up in 18996424-hc

Running Chrome 80.0.3987.116 on Windows 10. I was able to reproduce it on MacOS Chrome 79, but it went away when I updated to the latest version.

I've sent them this information to check: https://en.support.wordpress.com/third-party-cookies/

[GeoJunkie]

Reported in 14631267-hc
User Agent:
Safari 13.0 on Mac OS X 10.15.2

[gwwar]

Re-raised in p58i-89x-p2

[ramonjd]

Triaging this today. 👍

See: p58i-89x-p2#comment-45171

[JoshuaGoode]

19160280-hc

Safari 13.0 on Mac OS X 10.15.3

[tijosh]

2753501-zen

Microsoft Edge, possibly also the WordPress.com app

[ramonjd]

If anyone has time to test https://github.com/Automattic/wp-calypso/pull/39859

I'm hoping that it might be a mitigating change

[lancewillett]

@ramonjd I tested the pull request and left notes there. Could we push it live, and see if it reduces the user reports?

[ramonjd]

@lancewillett Thanks for testing. I was hunting about for a ✅ @michaeldcain helped test as well so I'll throw it up and see if nothing 💥 :)

[blowery]

@johnwilander it's not specifically ITP, but https://bugs.webkit.org/show_bug.cgi?id=202137 is causing us a lot of pain. It would be lovely if that could be escalated.

[philnick206]

Another report in #21648700-hc

Using Chrome and WordPress app. Fresh download of Firefox was ok.