Preview sometimes 404s (more often on Safari) #30145
Comments
AMcGrady
added
[Type] Bug
|
Reported on 1710205-zen |
|
Reported here 1751630-zen |
|
Reported here: 1850115-zen |
|
I think this might be a duplicate of #29324, which may be related to WordPress/gutenberg#13232 |
|
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. |
|
Got another report here 4607264-hc. Not sure what to do about the duplicate that mentioned @kristarella 😅 — this one seems specific to Safari (?) |
|
@AtrumGeost I think they are all related and the issue is just worse in Safari because Safari has an über sticky cache |
|
Reported here: 1872673-zen |
|
Reported here: 1872683-zen |
|
Another one 1868632-zen |
|
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. |
|
Issue reported again here: I was able to reproduce the issue: Preview for the same post works in Chrome but not in Safari: Chrome: Safari: |
|
@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? |
|
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? |
|
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. |
|
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. |
|
I also found this issue - #33799 - which seems directly related. |
|
Another report in #14430653-hc. |
|
Another report in #2421103-hc using Safari |
|
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? #35824 |
|
Another report in 2381508-zen, using Chrome.
As a workaround, for now, I recommended the user to:
|
|
Report here #15587183-hc. I suggested the user clear browser cache and @eduardozulian's workaround (click Preview - close - reclick Preview again) |
|
Another report here #15576695-hc |
|
Related is #36837, though folks reporting this one will always 404. Going to update the summary to reflect some of the more recent comments. |
gwwar
changed the title
|
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 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 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. |
|
Encountered in mobile Safari in 17498480-hc |
|
Another report in 2595675-zen |
|
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! |
|
Another report in 2603690-zen and the user experienced the issue in both Safari and Chrome |
|
17608516-hc (Safari 13) |
|
17747626-hc Safari 13.0 on Mac OS X 10.14.6 |
|
16307010-hc Safari 12.1 on Mac OS X 10.13.6 |
|
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:
|
|
Another report in 2624369-zen with Safari 13.0.4 MacOS 10_15_2 |
|
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. |
|
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. |
|
Another report in 2660913-zen with Safari 13 |
|
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:
In Calypso the preview link is:
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... |
|
I had a report of this: Safari version: version 13.0.3 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 Firefox on a different device and confirmed it's just fine in FF, so it's isolated to Safari, it seems. |
|
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/ |
lancewillett
added
the
[Pri] High
|
Reported in 14631267-hc |
|
Re-raised in p58i-89x-p2 |
|
Triaging this today. 👍 See: p58i-89x-p2#comment-45171 |
|
19160280-hc Safari 13.0 on Mac OS X 10.15.3 |
|
#2753501-zen Microsoft Edge, possibly also the WordPress.com app |
|
If anyone has time to test #39859 I'm hoping that it might be a mitigating change |
|
@ramonjd I tested the pull request and left notes there. Could we push it live, and see if it reduces the user reports? |
|
@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 💥 :) |
|
@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. |
|
Another report in #21648700-hc Using Chrome and WordPress app. Fresh download of Firefox was ok. |
and others
Summary Update from @gwwar 10/22
Steps to reproduce
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
The text was updated successfully, but these errors were encountered: