Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features using alert(), confirm() or prompt() break in Chrome >= 92 when editor is iframed (including post privacy settings) #54781

Closed
fullofcaffeine opened this issue Jul 21, 2021 · 11 comments
Labels
[Closed] Not Reproducible Issue cannot be reproduced. [Feature] Post/Page Editor The editor for editing posts and pages. Needs triage Ticket needs to be triaged [Pri] Low [Status] Core Fix Needed A fix within the Core WordPress or Gutenberg project is required to resolve this issue. [Type] Bug User Report This issue was created following a WordPress customer report

Comments

@fullofcaffeine
Copy link
Contributor

fullofcaffeine commented Jul 21, 2021

Steps to reproduce the behavior

  1. Using Chrome 92 or greater, start a new post from Calypso
  2. Assuming the Desktop viewport, click on the gear icon the top-right corner,
  3. In the pane that appears, click in the "Post" tab
  4. Search for the "Status & visibility" and under it, for the "Visibility" label;
  5. On its right, it (probably) be shown as "Public", click it
  6. You'll see a popup titled "Post Visibility" with three options presented as radio-buttons
  7. Try to change to "Private". It silently fails to cause any side effects. Nothing happens*

*check the JS console warnings and you'll see why.

UPDATE: It also happens with the "Switch to draft" button.

What I expected to happen

I expect the confirmation JS dialog to appear and to be able to confirm that or cancel the operation of setting the post as private.

What actually happened

Nothing. Clicking the "Private" radio-button doesn't do anything. It just outputs a warning in the Chrome JS console.

Context

It seems it has been decided that cross-origin iframes can't trigger dialogs anymore as it was considered bad UX and a possible security breach. See: https://www.chromestatus.com/feature/5148698084376576. It has been active as a "trial" since Chrome 92 (and apparently until v96), see: https://developer.chrome.com/origintrials/#/view_trial/2541156089743802369.

For now, it only manifests in Chrome 92, but it might be a problem in Firefox and Safari soon, too (and possibly other browsers in the longer term):
Screenshot from 2021-07-21 18-16-46

This is not specific to Gutenberg at all. If you open the edit post page directly from wp-admin, everything works as expected (see screencast at the bottom of this issue).

Browser / OS version

92.0.4515.107 (Official Build) (64-bit), Linux.

Is this specific to the applied theme? Which one?

No.

Does this happen on simple or atomic sites or both?

Possibly both, but only tried in simple sites so far.

Is there any console output or error text?

Yes:

A different origin subframe tried to create a JavaScript dialog. This is no longer allowed and was blocked. See https://www.chromestatus.com/feature/5148698084376576 for more details.

Level of impact (Does it block purchases? Does it affect more than just one site?)

Reproducibility (Consistent, Intermittent) Leave empty for consistent.

Screenshot / Video: If applicable, add screenshots to help explain your problem.

Peek.2021-07-21.17-54.mp4

I'm using an older Gutenberg release in these tests as you may see the in the screencast above. I did that to rule out it being a problem introduced by the recent upgrades. It's not. It happens consistently with an older or a more recent release.

@fullofcaffeine fullofcaffeine added [Type] Bug Needs triage Ticket needs to be triaged labels Jul 21, 2021
@fullofcaffeine
Copy link
Contributor Author

cc @Automattic/team-calypso-frameworks

@fullofcaffeine fullofcaffeine changed the title Can't set post as private in Chrome >= 92 when editor is iframed Features using alert(), confirm() or prompt() break in Chrome >= 92 when editor is iframed Jul 21, 2021
@jsnajdr
Copy link
Member

jsnajdr commented Jul 22, 2021

Chrome 92 started blocking modals like window.confirm in cross-origin iframes. And they are blocked unconditionally even if I explicitly say that I want them with <iframe sandbox="allow-modals" />.

This needs a fix on the Gutenberg side, abandoning window.confirm in favor of something else, e.g., a custom modal box.

We can do a workaround on the Calypso iframe side by intercepting window.confirm. But because window.confirm() is synchronous, we can't replace it with a custom UI: the only option is not doing any user confirmation and returning true right away.

@Robertght
Copy link

Robertght commented Jul 29, 2021

One case in 4182598-zen

As a workaround, I recommended using the Classic editor.

@happychait
Copy link

happychait commented Jul 29, 2021

I had a report in #30840168-hc

I also experienced this problem myself in my own WordPress.com account. I use Chrome Version 92.0.4515.107 (Official Build) (x86_64).

Video showing the issue that nothing happens when I click on the Private radio button: https://cln.sh/v7oXtp

@KokkieH
Copy link
Contributor

KokkieH commented Jul 30, 2021

Another report in https://wordpress.com/forums/topic/can-make-posts-to-private/

They report it also happens in Edge, though I'm not able to reproduce it there. I can reproduce in Chrome.

@KokkieH KokkieH added User Report This issue was created following a WordPress customer report [Feature] Post/Page Editor The editor for editing posts and pages. labels Jul 30, 2021
@bsanevans
Copy link

Another report: 4181858-zd-woothemes

@supernovia
Copy link
Contributor

@inaikem inaikem changed the title Features using alert(), confirm() or prompt() break in Chrome >= 92 when editor is iframed Features using alert(), confirm() or prompt() break in Chrome >= 92 when editor is iframed (including post privacy settings) Aug 1, 2021
@poojashetty18
Copy link

Another report: 19996224-hc
They reported the issue on the Microsoft browser as well.

@renata-franco
Copy link

Reported here: 4180786
User did not say what browser they are using.

@cuemarie cuemarie added [Pri] Low [Status] Core Fix Needed A fix within the Core WordPress or Gutenberg project is required to resolve this issue. labels Jun 29, 2023
@cuemarie
Copy link

This report was found during a recent backlog sweep.

📌 SCRUBBING : RESULT - Replicated / Could Not Replicate / Uncertain

  • Tested on Simple - Could Not Replicate

📌 FINDINGS/SCREENSHOTS/VIDEO

  • Tested in Chrome 114 (current) and could not replicate.
maDUvy.mp4

📌 ACTIONS

  • Closed as no longer relevant/not reproducible

@cuemarie cuemarie closed this as not planned Won't fix, can't repro, duplicate, stale Jun 30, 2023
@cuemarie cuemarie added the [Closed] Not Reproducible Issue cannot be reproduced. label Jun 30, 2023
@github-actions
Copy link

Support References

This comment is automatically generated. Please do not edit it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Closed] Not Reproducible Issue cannot be reproduced. [Feature] Post/Page Editor The editor for editing posts and pages. Needs triage Ticket needs to be triaged [Pri] Low [Status] Core Fix Needed A fix within the Core WordPress or Gutenberg project is required to resolve this issue. [Type] Bug User Report This issue was created following a WordPress customer report
Projects
None yet
Development

No branches or pull requests

10 participants